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

Daniel Micay danielmicay at gmail.com
Fri Jan 10 22:20:52 PST 2014

On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson <banderson at mozilla.com> wrote:
> 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.

The branch on the overflow flag results in a very significant loss in
performance. For example, I had to carefully write the vector `push`
method for my `Vec<T>` type to only perform one overflow check. With
two checks, it's over 5 times slower due to failed branch predictions.

More information about the Rust-dev mailing list