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

Brian Anderson banderson at mozilla.com
Fri Jan 10 22:18:12 PST 2014


On 01/10/2014 10:08 PM, Daniel Micay wrote:
> 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.

I do think it's useful and is potentially a good compromise for the 
performance of the default integer type. Overflow with failure is a bug 
that tells you there's a bug. Wrapping is a bug that pretends it's not a 
bug.

Hitting a slow path unexpectedly on overflow seems to me like a recipe 
for unpredictable performance, which doesn't seem inline with Rust's 
usual goals.


More information about the Rust-dev mailing list