Corner case for encoding delta value

, ,
1

Imported from previous forum

2

Hello,

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.

Now, for the receiving side, when you get this value (which end up being 5F92 in hexa), it looks like some decoders are using the first bit as the sign bit (which would be bit #13 in my example, the one just after the stop bit 0).

What am I missing here? Is the encoding described above expected?

Thanks,
Fred.

3

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.

4

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.