Arbitrary precision rational arithmetic

[sparkprime]

Using double precision floating point has its flaws, e.g. rounding errors. It makes sense to use arbitrary precision rational arithmetic in Jsonnet. We will have to find a library with a decent license that does not bloat the binary size too much, and then replace the current number representation.

[sparkprime]

I think at this point we're committed to double precision floating point.

[dynaxis]

I got stuck with the limitation of double representation of numbers. Could you reconsider support of arbitrary precision for numbers?

[sbarzowski]

@dynaxis Can you tell us more about your use case?

We don't expect to change it (that's why it was closed), but it's not completely out of question.

[dynaxis]

I'm using jsonnet to write JSON schemas. There, I need to write int range constraints comparable to int64. But I can't even write the type's min and max values as literal numbers since it requires more than 53 bits.

[sbarzowski]

Thanks. This seems like a very reasonable use case to me.

In the short-term it is possible to implement a workaround: a custom manifestJSON which serializes your custom objects as long numbers (internally you could then represent them as strings or something). LMK if you want to go this way and need help with that.

Please note that the JSON specification allows the implementations to set limits on the precision, and recommends to avoid requiring more precision. A lot of JSON parsers have limitations there (Javascript, QT, Go with default settings...). So if you have control of the schema, perhaps it's better to avoid the need for large numbers there (e.g. by using a larger unit).

This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
generally available and widely used, good interoperability can be
achieved by implementations that expect no more precision or range
than these provide, in the sense that implementations will
approximate JSON numbers within the expected precision. A JSON
number such as 1E400 or 3.141592653589793238462643383279 may indicate
potential interoperability problems, since it suggests that the
software that created it expects receiving software to have greater
capabilities for numeric magnitude and precision than is widely
available.

Source: https://tools.ietf.org/html/rfc7159#section-6

[dynaxis]

Thanks for the clarification. I'll think more about how I'll proceed taking your suggestion into acount.