[This message was posted by Fred Malabre of CME Group <[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/546ef683 - PLEASE DO NOT REPLY BY MAIL.]
Thanks Dale, your explanation makes sense. > Hi Fred, > > > Let's say I have a field defined as U64 to encode with delta value. > > The reference value is 0. I want to send the value 12178 (then as a signed > > value because of delta encoding). > > The corresponding binary value is 0000 ... 0000 0010 1111 1001 0010. > > Encoding with FAST, I would end up with: > > (0)101 1111 (1)001 0010 > > => Continuation byte is in parenthesis in the example above. > > => Only 2 bytes are sent according to the rule truncating most significant > > bits set to zero. > > This is where the misunderstanding arises. There is a significant leading > zero bit on this number because it is a positive signed number. The encoding > you have shown discards this significant bit. The correct FAST encoding > takes 3 bytes: > > (0)... ...0 (0)101 1111 (1)001 0010 > > I am using a dot to represent insignificant bits which are actually > transmitted as zero bits. Even though the first byte is zero, this is not an > over-long encoding. An overlong encoding would have all insignificant bits > in the first byte. > > HTH, > > Dale > -- > Principal Software Engineer > Object Computing, Inc. > Lead Developer of the QuickFAST open source implementation of FAST. [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.
