
Boost : 
From: fernando_cacciola_at_[hidden]
Date: 20021021 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  HighPrecision Arithmetic Query
> Just a quick query about what you guys think should be done in overflow
> situations with highprecision 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
most arquitectures.
As a numerical programmer, I've always found this to be more a problem than
a gain.
Sure, it is faster, but not so any more but when overflow actually
happens,
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
impossible.
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
'1000....'
(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'scomplement masks the overflow
when converting
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
should fail.
Fernando Cacciola
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk