Use arbitrary precision rationals as the underlying representation of numbers #1182
Conversation
First draft of implementing Nickel numbers using arbitrary precision rationals instead of 64-bits float. The rationale is to provide exact precision for common arithmetic operations (understand addition, division, subtraction, raising to an integer power, modulo), as opposed to floats, that can incur rounding error on sometimes common decimal values. Some operations do need rounding: raising to a non-integer power, as well as representation as a string (to_string/serialization).
yannham
force-pushed
the
task/arbitrary-precision-numbers
branch
from
2383913 to
7513f5b
Compare
| if n < &Number::ZERO { | ||
| return Err(EvalError::Other( | ||
| format!( | ||
| "generate: expected the 1st argument to be a positive number, got {n}" |
There was a problem hiding this comment.
For the trace primop, I used the builtin.trace as the output prefix. Maybe this here should use array.generate as well? We're generally assuming that the functions in the stdlib are addressed by their full path (without trickery like let-rebinding).
There was a problem hiding this comment.
On one hand, this is not the stdlib function, this is the underlying primop. All other primops are doing the same right now (well, excepted for trace, apparently). It's not advised, but not out of the question, to use them somewhere else than in the stdlib (e.g. for performance reasons, maybe? Or will we just forbid them in user-code? I'm not sure). Anyway, the whole primop error reporting is a mess 😅 it's a very valid point but this code has just been moved around IIRC. I propose to do a pass on primop error reporting separately.
Co-authored-by: Oghenevwogaga Ebresafe <gaga.ebresafe@tweag.io>
Closes #1163.
This pull request introduces arbitrary precision rationals as the underlying number representation for Nickel, instead of the current 64-bits float. The motivation and the rationale of the specific design choices are detailed in #1163.
Choice of the arithmetic library
There are a few Rust crates for doing arbitrary-precision arithmetic:
Among the crates that are both WASM-capable and handle arbitrary precision rationals, I chose to go with
malachitewhich seemed to be the more solid. It's not out of the question to migrate to a different library anyway, if needed.