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 <co...@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 <leebr...@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@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
