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

Carter Schonwald carter.schonwald at gmail.com
Fri Jan 10 23:52:09 PST 2014

sounds like we agree!  (and thanks for clarifying some of the detail points
i neglected)

On Sat, Jan 11, 2014 at 2:27 AM, Daniel Micay <danielmicay at gmail.com> wrote:

> 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
> files.
> >
> > @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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/be469f54/attachment-0001.html>

More information about the Rust-dev mailing list