Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arbitrary precision rational arithmetic #2

Closed
sparkprime opened this issue Aug 10, 2014 · 6 comments
Closed

Arbitrary precision rational arithmetic #2

sparkprime opened this issue Aug 10, 2014 · 6 comments

Comments

@sparkprime
Copy link
Contributor

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
Copy link
Contributor Author

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

@dynaxis
Copy link

dynaxis commented Apr 9, 2020

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

@sbarzowski
Copy link
Collaborator

@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
Copy link

dynaxis commented Apr 10, 2020

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
Copy link
Collaborator

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
Copy link

dynaxis commented Apr 10, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants