[protobuf] int32 negative numbers
I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] int32 negative numbers
... for a negative number, the resulting varint is *always ten bytes long ...* I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] int32 negative numbers
On Sun, Mar 21, 2010 at 08:05, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: ... for a negative number, the resulting varint is always ten bytes long ... Reason for that is the varint encoding: it only encodes the bits that are set in an integer. For small positive values that results in a more compact format. However, negative values always have the very first bit set (the sign bit), so these values end up to be longer. If you have values that are centering around zero but whose absolute values usually don't use the full range, then the 'sint32' would be probably a better encoding for you: it is done in 'zigzag'-encoding that uses short encoding for small absolute values and longer for larger absolute values. If your numbers are big or pretty random, then you might consider fixed32. Note however, that changing the type from int32 to sint32 or fixed32 are not compatible - so if you've already data stored that way or have running services that talk RPC in that way, you need an upgrade path; probably adding a new field with the new encoding, setting it in parallel for some time (until all other users are gone). If you have stored data the old way and don't want to recode than you've to forever test - on reading - if the 'old' field exists and take that value. -h I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] int32 negative numbers
Thank you for your reply. Yes you are right. I just wondered why int32 consists of 10 bits, rather than a maximum of 5 (in the case of large or negative numbers). Adam 2010/3/21 Henner Zeller henner.zel...@googlemail.com On Sun, Mar 21, 2010 at 08:05, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: ... for a negative number, the resulting varint is always ten bytes long ... Reason for that is the varint encoding: it only encodes the bits that are set in an integer. For small positive values that results in a more compact format. However, negative values always have the very first bit set (the sign bit), so these values end up to be longer. If you have values that are centering around zero but whose absolute values usually don't use the full range, then the 'sint32' would be probably a better encoding for you: it is done in 'zigzag'-encoding that uses short encoding for small absolute values and longer for larger absolute values. If your numbers are big or pretty random, then you might consider fixed32. Note however, that changing the type from int32 to sint32 or fixed32 are not compatible - so if you've already data stored that way or have running services that talk RPC in that way, you need an upgrade path; probably adding a new field with the new encoding, setting it in parallel for some time (until all other users are gone). If you have stored data the old way and don't want to recode than you've to forever test - on reading - if the 'old' field exists and take that value. -h I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] int32 negative numbers
On Sun, Mar 21, 2010 at 8:54 AM, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: Thank you for your reply. Yes you are right. I just wondered why int32 consists of 10 bits, rather than a maximum of 5 (in the case of large or negative numbers). So that you can change an int32 to int64 without breaking compatibility. Adam 2010/3/21 Henner Zeller henner.zel...@googlemail.com On Sun, Mar 21, 2010 at 08:05, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: ... for a negative number, the resulting varint is always ten bytes long ... Reason for that is the varint encoding: it only encodes the bits that are set in an integer. For small positive values that results in a more compact format. However, negative values always have the very first bit set (the sign bit), so these values end up to be longer. If you have values that are centering around zero but whose absolute values usually don't use the full range, then the 'sint32' would be probably a better encoding for you: it is done in 'zigzag'-encoding that uses short encoding for small absolute values and longer for larger absolute values. If your numbers are big or pretty random, then you might consider fixed32. Note however, that changing the type from int32 to sint32 or fixed32 are not compatible - so if you've already data stored that way or have running services that talk RPC in that way, you need an upgrade path; probably adding a new field with the new encoding, setting it in parallel for some time (until all other users are gone). If you have stored data the old way and don't want to recode than you've to forever test - on reading - if the 'old' field exists and take that value. -h I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
