[boost] Re: Numeric Conversion Formal Review

From: Dan W. (danw_at_[hidden])
Date: 2003-12-12 07:21:42

 > > int main() {
 > >   int a = (1 << 24) - 1;
 > >   volatile float b = a;
 > >   volatile float c = b + 0.5f;
 > >   volatile float d = floorf(c);
 > >   int e = d;
 > >   assert((double)a == (double)b);
 > >   printf("%d %d\n", a, e);
 > >   return 0;
 > > }
 > >
 > > The integer is the biggest odd integer representable as simple
 > > precision floating-point number. So the conversion from float to int
 > > should not
 > > modify the value (since it already is an integer). However, as you can
 > > see, the final value is different from the first value. The same will
 > > happen with any odd integer between 2^23 and 2^24 (and their negative
 > > counterpart). So it's not a few cases, there is unfortunately a bunch
 > > of them.
 > >
 > Hmmm...
 > OK, I see the problem....
 > Seems difficult to deal with without compromising efficiency for the safe
 > cases (<2^23).

As a probable future user of numerical headers, I'd like to beg for simplicity.
The problems being discussed are not new, and any programmer that has the 
dimmest clue about numerical representations knows to expect nothing but 
bad news from floats.. ;-)

Please do whatever the hardware supports natively, and don't slow our 
computations for the sake of a few newbies that will initialize a float to 
2^30 and expect to get a different number when adding one...

True, I understand, floor() is a function that bears a specification. But 
where the specification can't be met, it should be fixed, not the 
computation.  People who know anything about floats and doubles will use 
them well below the range of their mantissa's bits as int, anyways.

You already offer rational numbers, and multiple precision numbers?, so 
those who need better than standard IEEE representations can use the better 
ones.

Just my $0.015