On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson <dbau...@gmail.com> wrote: > On 11/01/14 16:58, Isaac Dupree wrote: >> >> Scheme's numeric tower is one of the best in extant languages. Take a >> look at it. Of course, its dynamic typing is poorly suited for Rust. >> >> Arbitrary-precision arithmetic can get you mathematically perfect integers >> and rational numbers, but not real numbers. There are an uncountably >> infinite number of real numbers and sophisticated computer algebra systems >> are devoted the problem (or estimates are used, or you become unable to >> compare two real numbers for equality). The MPFR C library implements >> arbitrarily high precision floating point, but that still has all the >> pitfalls of floating-point that you complain about. For starters, try >> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >> >> In general, Rust is a systems language, so fixed-size integral types are >> important to have. They are better-behaved than in C and C++ in that signed >> types are modulo, not undefined behaviour, on overflow. It could be nice to >> have integral types that are task-failure on overflow as an option too. > > > We do already have some Checked* traits (using the LLVM intrinsics > internally), which let you have task failure as one possibility on overflow. > e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html > (and Mul, Sub, Div too).
I don't think failure on overflow is very useful. It's still a bug if you overflow when you don't intend it. If we did have a fast big integer type, it would make sense to wrap it with an enum heading down a separate branch for small and large integers, and branching on the overflow flag to expand to a big integer. I think this is how Python's integers are implemented. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
