ow Integers Should Work

[Walter Bright]

On 12/5/2011 1:37 PM, Don wrote:
> The "overflow12.pdf" paper on that site shows statistics that overflow is very
> often intentional. It's strong evidence that you *cannot* make signed overflow
> an error. Even if you could do it with zero complexity and zero performance
> impact, it would be wrong.

Here's an email from Andy Koenig from the C++ mailing list that I think is very 
relevant (there are a lot of very experienced people on that list, lots of 
mistakes we can avoid by listening to them):
-----------------------------------------
Subject: [c++std-ext-11967] Re: Two's-Complement Arithmetic
From: "Andrew Koenig" <ark at acm.org>
To: <c++std-ext at accu.org>
Date: Mon, 5 Dec 2011 22:08:29 -0500

 >> With respect to overflow, I wonder how many of these issues would
 >> not be better addressed with a Scheme-like bignum type that is cheap
 >> for (31- or) 63-bit integers, and involves memory allocation only on
 >> overflow.

 > +1, would love to have had this years ago.

Sounds a little like Python 3 integers.

And while I'm thinking about Python 3 arithmetic, there's something else in
Python 3
That I'd love to have in C++, namely a guarantee that:

1) Converting a string to a floating-point number, whether through
input
at run time or writing a floating-point literal as part of a
program,
always yields the correctly rounded closest floating-point value to
the infinite-precision value of the literal.

2) Converting a floating-point number to a string without a
specified
number of significant digits yields the string with the smallest
number of
significant digits that, when converted back to floating point
according
to (1), yields exactly the same value as the one we are converting.

Techniques for solving these problems were published more than 20 years ago,
so it's hard to argue against them on the basis of novelty.  Moreover, these
rules
would have some nice properties, among them:

Printing a floating-point number without specifying accuracy and
reading
it back again into a variable with the same precision gives you the
same value.

Printing a floating-point literal with default precision gives you
the same value as the literal unless the literal has too many
significant digits to represent accurately.

References here:

http://www.cs.washington.edu/education/courses/cse590p/590k_02au/print-fp.pdf
http://www.cs.washington.edu/education/courses/cse590p/590k_02au/read-fp.pdf