Imported from previous forum
[ original email was from Jonas Nordin - jonas.nordin@omxgroup.com ]
I have two questions regarding delta encoding.
Delta encoding for decimal values
In the FAST Field encoding specification 1.0 there is no special mention of delta encoding for decimal values my assumption was that you calculate the delta using the decimal values and then encode the result(with a possible loss of accuracy).
The FAST template specification 0.38 has the following description
“The delta value is encoded as two separate stop-bit encoded signed integers. The first integer is the delta for the exponent and the second is the delta for the mantissa. The combined value is calculated by applying the two deltas to their counterparts of the base value.”
Should this be interpreted as delta encoding of decimals implicitly uses the twin-field encoding (=two bits in the presence map)?
Delta encoding for strings
The delta encoding algorithm for strings differs between the two specifications. The field encoding specification only describes delta encoding as
“For character string fields, the delta is defined as being the tail characters of the field. As a consequence, the delta value coding can only be used on character string fields with a fixed length.”
While the template definition specification describes it as
“The delta value has two parts that are encoded as a single stop-bit encoded entity. The first byte contains a 7 bit signed integer indicating the number of bytes to remove from the front or back of the base value. Bytes are removed from the front when the number is negative. Following the leading byte there are zero or more bytes to add to the same end of the base value as indicated by the sign of the leading number.”
Which one is the correct algorithm to use for delta ASCII-string values?
Jonas Nordin
[ original email was from David Rosenborg - David.Rosenborg@pantor.com ]
> In the FAST Field encoding specification 1.0 there is no special mention
of delta encoding for decimal values my assumption was that you
calculate the delta using the decimal values and then encode the
result(with a possible loss of accuracy).
It’s not specified but I think that your assumtion is in line what most people would think of delta for decimals in FAST 1.0.
The FAST template specification 0.38 has the following description
“The delta value is encoded as two separate stop-bit encoded signed
integers. The first integer is the delta for the exponent and the second
is the delta for the mantissa. The combined value is calculated by
applying the two deltas to their counterparts of the base value.”Should this be interpreted as delta encoding of decimals implicitly uses
the twin-field encoding (=two bits in the presence map)?
This is currently under development but the delta value of a decimal is special, it is not a scaled number event thought it structurally consits of two stop bit coded entities the exponent delta and the mantissa delta. The term twin-field decimal will most likely disappear.
The rationale for having separate deltas for exponent and mantissa is that then you can express deltas without loss of precission.
If you for example have 17 * 10^30 and the next value is 1 * 10^-30 you wouldn’t be able to express the difference as a normal decimal number. If you treat the exponent and mantissa separatley it works because then you’d transmit {-60, -16}
Delta encoding for strings
The delta encoding algorithm for strings differs between the two
specifications. The field encoding specification only describes delta
encoding asWhich one is the correct algorithm to use for delta ASCII-string values?
If you intend to implement FAST 1.0, use the one defined there. It’s still discussed how string deltas will look in the upcoming version of FAST.
/David