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

Daniel Micay danielmicay at gmail.com
Fri Jan 10 22:08:15 PST 2014

On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson <dbau.pp at 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.

More information about the Rust-dev mailing list