[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
danielmicay at gmail.com
Sat Jan 11 11:43:25 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
>>>> and rational numbers, but not real numbers. There are an uncountably
>>>> infinite number of real numbers and sophisticated computer algebra
>>>> 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
>>>> 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
>>> 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.
This is why `clang` exposes sanitize options for integer overflow. You
could use `-ftrapv` in production... but why bother using C if you're
taking a significant performance hit like that?
> 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
It's certainly better than the process exiting, which is what's going
to happen in real systems when failure occurs. Either that, or they're
going to lose a bunch of data from the task it caused to unwind. The
only way to make overflow not a bug is to expand to a big integer or
use a big integer from the start.
More information about the Rust-dev