[This message was posted by Dan Pike of <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/f5f8103e - PLEASE DO NOT REPLY BY MAIL.]
Has anyone read the FAST specification recently and noticed some strange discrepancies in the examples? Maybe I'm lacking some sleep, but, I believe that the tables are inconsistent in the way that they present the encoded data. For an example of what is confusing me, consider example 3 of Appendix 3.2.4. For the first row, the Encoded Value is set to "N/A-N/A", so how does the receiver deduce that the second value should be 12100? Admittedly, I have only read through the specification once but the way that I read it, a transmitted value of 0xff 0xed is required to get from 12000 to 12100? I didn't notice anything in the spec that confirms whether the receiver preloads the prior value as 0 or as 12000 for this case, but I assume that it starts at 12000, otherwise there'd be little point in having support for initial values, As for the rest of that table. there didn't seem to be any consistency in how the rows and columns relate to each other. Even when I would have expected them to be unambiguous, the numbers don't seem to add up. For example, when it lists the encoded values as -2/1198, it translates these to FAST 0xfe/0x9/0xae. 0xfe makes sense but I think that 0x9/0xae translates to 2350, doesn't it? Where did the 1198 go to, or the 2350 come from? Please help a very confused newbie! [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
