Re: Questioning support for Type Conversion
Rolf Andersson / Pantor Engineering
14 Apr 2006 2:02AM ETThe section on type conversions relates to a previous discussion
on converting back and forth between ASCII formatted numbers in
FIX.
For example;
"100000" has multiple possible representations in FAST.
1. "100000" - a string
2. 100000 - an (un)signed integer
3. 1E5 - a decimal with exponent=5 and mantissa=1
Alternative 1 would yield a 6 byte wire representation,
2 => 3 bytes and 3 => 2 bytes.
The number can be unabiguously converted back and forth.
Let's take another example;
"001000" again has multiple representations fot the _value_, but
the added problem of leading zeroes is difficult to solve in a
straight forward way in FAST.
The obvious alternative is to use a string representation in
FAST but this comes at the extra cost of using 6 bytes instead
of 2 bytes for a binary representation (integer or decimal).
"001000" => 1000 (or 1E3) => "1000" would break format identity
but would preserve the original numeric value.
I believe type conversions are relevant to discuss in the context
of values versus representations in unecoded streams.
We may want to break this section out of the TD spec, but it is
important that we describe this problem and at least provide some
guidance as how to encoding and decoding should be done.
The cases I've seen with e.g. "0048" instead of "48" have been
optimizations for body length where an implementation reserves
space in the output buffer and then patches the buffer when the
rest of the message is completed (and the length is known) but
before calculating the message checksum.
There is another related case where the display format is encoded
into the value of a FIX field.
For example:
"121.50" has the same value as "121.5" but "121.50" also conveys
how the value could (should) be displayed.
I believe this to be a mixup of concerns. The number of displayed
decimals should be conveyed separately (and transferred whenever
the number changes), not as an implicit part of the value.
There is however a way to represent (with less efficiency) the
value in a way that could be applied to retain the extra decimal
place (even though the last zero is insignificant).
"191.50" => 19150E-2 => "191.50"
(instead of "191.50" => 1915E-1 => "191.5")
(1915E-1 => 3 bytes, while 19150E-2 => 4 bytes)
Anyway, I believe we need to discuss this further.
> During my initial review of the FAST Template Definition (TD)
> Speciifcation - the specification of type conversion is one point
> that I really felt was embellishment and should not be part of the
> FAST Protocol and should be omitted.
> This is better left to implementors.
>
> There is a difference between an API and a library layer of
> convenience functions and presentation services. I believe we
> should stay below these levels and omit this practice.
>
> Also, FAST is a message protocol, and while it does have datatypes,
> it does not have the demands for type conversion/coercion implicit
> or otherwise as that of a programming language.
>
> I would also point out that type safety and coercion / conversion
> rules are a rife area for philosophical debate within computer
> science, and as such I would like to exclude this layer and these
> arguments as being of diminished value for the application of our
> very limited time in specification creation and maintenance.
>
> With that said, I also think I am one of the less capable folks in
> this discussion – so I would like some feedback and justification
> if others feel strongly that we should expand the scope of the FAST
> specification to include type conversion / coercion.
