On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson <[email protected]> wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson <[email protected]> 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.
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 > goals. 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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
