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

Carter Schonwald carter.schonwald at gmail.com
Fri Jan 10 23:06:25 PST 2014


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,

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)

@patrick
yes, (u)int types that are the same size as pointers are good for indexing
into in memory arrays!

 What int type is suitable for indexing into larger than ram sized arrays
that are memmapped in regions in a demand driven way?
 (this is actually a problem i'm trying to figure out generally for some of
my own engineering work currently, and it really needs a way that lets one
talk about larger than ram arrays on 16, 32 and 64 bit systems, because
those exist! Also similar problems come up when working with distributed
arrays too! The latter perhaps using something like openmpi or infiniband
as the management layer)

@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.

@bob also good point about generic support for integer/rational/floating
point literal support. Providing good literal support for those via a
suitable trait would probably help this become a much less contentious
issue (though if done poorly it does create some lockin woes)

anyways: numerical library design is very hard, and all i can say is I hope
that at least for the near term that rust errs on the side of avoiding
lockin on a bad design. And any call to action needs to have very concrete
worked out details, because the devil is in those details (well,
recursively even!)

keep up the great work!
-Carter



On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson <corey at octayn.net> wrote:

> The current consensus on this subject, afaik, is the rename int/uint
> to intptr/uintptr. They're awful names, but it frees up int for a
> *fast* bigint type. Fast here is key. We can't have a suboptimal
> numeric type be the recommended default. We need to perform at least
> as well as GMP for me to even consider it. Additionally we'd have
> generic numeric literals. I don't think anyone wants what we current
> have for *numerics*. Fixed-size integers are necessary for some tasks,
> but numerics is not one of them.
>
> As long as we rename int/uint to intptr/uintptr and leave int etc
> reserved, I think we can defer the language issues to post-1.0. It
> should be entirely backwards compatible. Development of robust
> numerics can happen outside the standard library. Talk to bjz about
> this, he has some ideas :)
>
> As an aside, you mention a "real" in your blog post like it's
> something that exists. Rust does not have any such type.
>
> On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden <leebraid at gmail.com> wrote:
> > This may be go nowhere, especially so late in Rust's development, but I
> feel
> > like this is an important, relatively small change (though a high-profile
> > one).  I believe it could have a large, positive impact in terms of
> > targeting new developer communities, gaining more libraries and
> > applications, giving a better impression of the language, AND on
> performance
> > and futureproofing.
> >
> > However, a lot of people who are interested in performance will probably
> > baulk at this, on first sight.  If you're in that group, let me encourage
> > you to keep reading, at least until the points on performance
> improvements.
> > Then baulk, if you like ;)
> >
> > Also, I said it in the post as well, but it's late here, so apologies for
> > any readability / editing issues.  I tried, but sleep beckons ;)
> >
> >
> >
> >
> http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/
> >
> >
> > --
> > Lee
> >
> >
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/d5747c74/attachment.html>


More information about the Rust-dev mailing list