[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Daniel Micay danielmicay at gmail.com
Fri Jan 10 23:27:16 PST 2014

On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> corey, those would be very very nice refinments and a healthy progressive
> yet conservative stance that leaves the room for evolving healthy defaults
> (I've a slow boil program to bring breaking changes to fix numerical warts
> in haskell over the next 2-3 years, )
> @corey, one example of a "Real" number type can be found in mpfr
> http://www.mpfr.org/ (C library for multiple-precision floating-point
> computations with correct rounding), though note its LGPL,

You choose a precision upon construction of a floating point value.
You also have to choose the precision for the output values. The
correct rounding is in comparison to the raw `mpf_t` offered by GMP
that I think it uses under the hood.

> on the rational number front, i believe theres 1-2 decent bsd/mit style such
> libs, and i know in haskell, GHC devs are evaluating how to move away from
> GMP (though this may not have any impact till whenver ghc 7.10 happens)

None of which are comparable in performance for anything but small
integers. LGPL isn't really that big a deal, because the implication
for closed-source projects is that they have to ship linkable object
> @Bob, well said! Even ignoring floating point imprecision, numerical
> computing still has to deal with rounding, well conditioned / wellposed-ness
> of the problem being solved, and  to some extent performance! Any "exact
> real" type either is unbounded (and thus provides unbounded performance woes
> if used carelessly) or bounded and will eventually suffer some precision
> issues in some example along with being several orders of slower.

No real number type has unbounded precision. Arbitrary precision means
the user passes the precision they desire up-front.

On the other hand, a rational number type implemented with big
integers will never lose any precision. However, you don't get `sqrt`,
`sin`, `cos`, etc.

More information about the Rust-dev mailing list