ugorji / binc Goto Github PK

Binc uses BigEndian format for encoding Integers, which is ok.
However, majority of CPUs (Intel, AMD, ARM) are inherently Little Endian.
If that is the case, why do conversion from Big Endian to Little endian and vice-versa, at the wire protocol.

Make Little Endian as the default encoding format for Integers.
Will that be a pragmatic approach ?

Even other emerging formats Capnproto (Google Protobuf successor) adopts LittleEndianness, precisely for the above reasons.

LittleEndianness will definitely speedup both encoding/decoding significantly.
Befor BINC is widely adopted, I think you may still consider changing it to Little Endianness.

I saw this beautifully constructed representation, and it is probably the best out there.

However, there are still some improvements to make in my opinion:

1. special value should not have zero for both float and int. One is enough.
2. symbol seems to be a compressor's task.
3. single byte for 1-16 is unneeded.
4. timestamp could be improved by indicating UTC only. other timezone can infer from this value.
5. overflow issue: for map and array, it could be over 2^64-1 in length.

I'm curious about support for Golang big.Int in binc.

I was happy to see support for long integers discussed early in the SPEC for binc. At the beginning of the spec it says there is support for

arbitrarily large precision negative and positive integers; Uses up to 2^64-1 bytes to represent integer value (for bignums, etc)

However, at the end, there is this w.r.t. to the Go implementation

For example, the Go library lists the following unsupported features:

integer values beyond 64 bit integers

Could you elaborate on whether big.Int numbers are supported at present? How difficult would it be to add big.Int encoding and decoding?

Thank you!

Jason

How binc is related with http://tools.ietf.org/html/rfc7049 ?
Will code implement rfc7049 ?

From data analysis and statistics, it is common to need to be able to represent that a particular piece of data is missing, or 'Not Available'. This is commonly abbreviated NA.

'Not Available' or NA or "Missing" is really a distinct notion, statistically, from Null and NaN.

Since R was built for data analysis, it has the NA special value built in. I believe R uses one of the multiple NaN values to represent this, but this is just convention.

I very much like that Binc has special values already for +/- Infinity, for NaN, and for Null.

It would be lovely to have the specification also choose a well-defined special value for NA or "NotAvailable".