Imported from previous forum
On the MDOWG call today - the concept was presented to include additional metadata attributes for things such as precision (scale) of a time field (millisecond, microsecond, nanosecond) or implied decimal place.
In thinking about this a bit more - that using constant encoding and having these attributes be able to be processed using the standard FAST 1.1 mechanism as it now exists keeps things simple and minimizes the complexity of the template.
One could probably argue successfully that having such data represented as constants accomplishes the same benefits with less complexity. True, constant fields don’t necessarily enforce concepts, such as the precision of a time representation, but I think this can be replaced by standardizing conventions.
Much was said on the call today regarding the complexity of the decimal datatype in FAST, which could have been represented by convention as two integer values, thus reducing the complexity of FAST implementations at the expense of the loss of enforcements on type.
In the case of additional attributes in the template language - I would argue for avoiding embellishing the template definition language and structure, instead extending the concepts already in place and using agreed upon conventions.
Jim -
From your post it is not clear to me if you talk about the use of foreign attributes or adding new first class attributes to the FAST specification. I guess you’re saying something like “foreign good, first class bad”, but I’m not sure I interpreted it correctly.
/David
On the MDOWG call today - the concept was presented to include
additional metadata attributes for things such as precision (scale)
of a time field (millisecond, microsecond, nanosecond) or implied
decimal place.In thinking about this a bit more - that using constant encoding and
having these attributes be able to be processed using the standard FAST
1.1 mechanism as it now exists keeps things simple and minimizes the
complexity of the template.One could probably argue successfully that having such data represented
as constants accomplishes the same benefits with less complexity. True,
constant fields don’t necessarily enforce concepts, such as the
precision of a time representation, but I think this can be replaced by
standardizing conventions.Much was said on the call today regarding the complexity of the decimal
datatype in FAST, which could have been represented by convention as two
integer values, thus reducing the complexity of FAST implementations at
the expense of the loss of enforcements on type.In the case of additional attributes in the template language - I would
argue for avoiding embellishing the template definition language and
structure, instead extending the concepts already in place and using
agreed upon conventions.
[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
Jim,
I quite agree with your point about avoiding foreign attributes to express features already present in FAST. It seems like a lot of time spent re-inventing Decimal.
The idea put forward was to send time in a scaled number as an Integer with ‘x’ implied decimal places where ‘x’ is defined in the templates foreign attributes.
This is redundant.
A Decimal type with a constant exponent is EXACTLY an Integer with x implied decimals places.
Part of the talk was being able to handle ints more quickly than Decimals. On the wire, of course, an Integer and a Decimal with a const exponent are exactly the same, so it is only a question of careful software design to handle const exponent Decimals as quickly as Integers with implied decimal places defined in foreign attributes.
As time goes on, it makes sense to me that we will want more precision in our timestamps. A Decimal containing seconds since unix epoch seems sensible. Systems sending time in seconds use a template with a const exponent of 3. Systems sending milliseconds with use a template with a const exponent of 3. People who want to send something more, can.
For example, you might send the current time as seconds, milliseconds, or microseconds, using a const exponent of 0, 3, or 6, respectively. The mantissa:
123
123.456
123.456789
If you don’t want the fractional part or don’t want more than milliseconds, you can discard.
Greg.
Jim -
From your post it is not clear to me if you talk about the use of
foreign attributes or adding new first class attributes to the FAST
specification. I guess you’re saying something like “foreign good, first
class bad”, but I’m not sure I interpreted it correctly./David
On the MDOWG call today - the concept was presented to include
additional metadata attributes for things such as precision (scale)
of a time field (millisecond, microsecond, nanosecond) or implied
decimal place.In thinking about this a bit more - that using constant encoding
and having these attributes be able to be processed using the
standard FAST
1.1 mechanism as it now exists keeps things simple and minimizes the
complexity of the template.One could probably argue successfully that having such data
represented as constants accomplishes the same benefits with less
complexity. True, constant fields don’t necessarily enforce concepts,
such as the precision of a time representation, but I think this can
be replaced by standardizing conventions.Much was said on the call today regarding the complexity of the
decimal datatype in FAST, which could have been represented by
convention as two integer values, thus reducing the complexity of FAST
implementations at the expense of the loss of enforcements on type.In the case of additional attributes in the template language - I
would argue for avoiding embellishing the template definition language
and structure, instead extending the concepts already in place and
using agreed upon conventions.
Greg,
as I interpret what you say below you are suggesting that we should expect implementors to specialcase the handling of a decimal in the case where it is really a timestamp?
/Rolf
Jim,
I quite agree with your point about avoiding foreign attributes to
express features already present in FAST. It seems like a lot of time
spent re-inventing Decimal.The idea put forward was to send time in a scaled number as an Integer
with ‘x’ implied decimal places where ‘x’ is defined in the templates
foreign attributes.This is redundant.
A Decimal type with a constant exponent is EXACTLY an Integer with x
implied decimals places.Part of the talk was being able to handle ints more quickly than
Decimals. On the wire, of course, an Integer and a Decimal with a const
exponent are exactly the same, so it is only a question of careful
software design to handle const exponent Decimals as quickly as Integers
with implied decimal places defined in foreign attributes.As time goes on, it makes sense to me that we will want more precision
in our timestamps. A Decimal containing seconds since unix epoch seems
sensible. Systems sending time in seconds use a template with a const
exponent of 3. Systems sending milliseconds with use a template with a
const exponent of 3. People who want to send something more, can.For example, you might send the current time as seconds, milliseconds,
or microseconds, using a const exponent of 0, 3, or 6, respectively.
The mantissa:
123
123.456
124.456789If you don’t want the fractional part or don’t want more than
milliseconds, you can discard.Greg.
Jim -
From your post it is not clear to me if you talk about the use of
foreign attributes or adding new first class attributes to the FAST
specification. I guess you’re saying something like “foreign good,
first class bad”, but I’m not sure I interpreted it correctly./David
On the MDOWG call today - the concept was presented to include
additional metadata attributes for things such as precision (scale)
of a time field (millisecond, microsecond, nanosecond) or implied
decimal place.In thinking about this a bit more - that using constant encoding
and having these attributes be able to be processed using the
standard FAST
1.1 mechanism as it now exists keeps things simple and minimizes the
complexity of the template.One could probably argue successfully that having such data
represented as constants accomplishes the same benefits with less
complexity. True, constant fields don’t necessarily enforce
concepts, such as the precision of a time representation, but I
think this can be replaced by standardizing conventions.Much was said on the call today regarding the complexity of the
decimal datatype in FAST, which could have been represented by
convention as two integer values, thus reducing the complexity of
FAST implementations at the expense of the loss of enforcements
on type.In the case of additional attributes in the template language - I
would argue for avoiding embellishing the template definition
language and structure, instead extending the concepts already in
place and using agreed upon conventions.
[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
Hey Rolf,
Any number with a fixed number of decimal places can be easily expressed as an integer. This is naturally expressed in FAST as a Decimal with constant exponent.
This can be a number of seconds, or milliseconds, or it can be pennies (such as a price type field), whatever.
My suggestion to specialize the handling of constant exponents was a response to concerns that integer handling with implied decimals would faster. Really, it is the same thing, so it can be as fast either way. It’s simply that Decimals are already supported in FAST. Foreign attributes describing implied decimals don’t really impart information unless you (or the decoder) know to look for them.
Regards, Greg.
Greg,
as I interpret what you say below you are suggesting that we should
expect implementors to specialcase the handling of a decimal in the case
where it is really a timestamp?/Rolf
…