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 <danielmi...@gmail.com> wrote: > On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald > <carter.schonw...@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. >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
