Date: 2002-10-21 10:21:22
----- Original Message -----
From: "Paul Mensonides" <pmenso57_at_[hidden]>
To: "Boost Developers" <boost_at_[hidden]>
Sent: Saturday, October 19, 2002 4:23 AM
Subject: [boost] Boost.Preprocessor - High-Precision Arithmetic Query
> Just a quick query about what you guys think should be done in overflow
> situations with high-precision arithmetic in the preprocessor library. I
> have three options:
> 1) return a known (and detectable) error state
> 2) saturate at the greatest value
> 3) cause a glorious preprocessor failure
I think that the only truly useful options are (3) or [1+2].
That is, either (1) or (2)[or any variance of 2] alone are useless.
Others have recall that C's integral types don't usually signal overflow on
As a numerical programmer, I've always found this to be more a problem than
Sure, it is faster, -but not so any more- but when overflow actually
many applications just drain into disaster.
The only reason -IMHO- why people don't care about integer overflow is
because it rarely
occurs, and when it occurs, it goes unnoticed.
Writing a *robust* program in the absence of signaling overflow is almost
How would you correctly implement something as naive as this:
int a_number = <...>;
int the_opposite = -a_number ;
Most programmers are not aware that if "a_number" is the bit pattern
(0x800...), then "the_opposite==a_number".
I've seen this sort of bug totally ruin many numerical algorithms.
The real problem in the case above is that 2's-complement masks the overflow
from the minimum negative value to the maximum positive value
(the positive range has one element less);
So, I think this is one of the things that we should *not* inherit from C.
It is OK to return a fake result (say a saturated number) but only as long
as the user can tell so.
If it is impractical to signal the overflow along with the saturated result,
then the operation
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk