Boost logo

Boost :

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2000-07-27 10:14:06

Regret a house move means I will not be doing anything on math constants for
some weeks - no phone yet!

But this looks a possibele problem.



> -----Original Message-----
> From: John Maddock [mailto:John_Maddock_at_[hidden]]
> Sent: Wednesday, July 26, 2000 12:44 PM
> To: INTERNET:boost_at_[hidden]
> Subject: RE: [boost] math constants
> Paul,
> >[PAB] Probably best, though won't this mean that user defined types
> always have to be specialised,
> when they might rely on conversion to double?<
> You mean conversion from double? I guess maybe that would work, but
> currently quite a few of the methods are unimplemented. Most current
> traits classes (for example numeric_limits char_traits etc
> don't provide
> default implementations.
> >[PAB] Since there are so many sig figs, surely should get the nearest
> >possible representation in a long double?
> In the long double yes, but when that gets rounded again to a
> float (or
> double) the result may not be the nearest representation.
> Imagine that float has 3 binary digits of precision, and long double 6
> digits, and that the actual number is exactly:
> 1.01011110
> rounded to our imaginary float type the nearest representation is 1.01
> rounded to our imaginary long double type the nearest
> representation is
> 1.01100
> and when this gets rounded again to a float (by rounding ties to the
> nearest even number) the result is 1.10 ... which isn't correct.
> Whether this situation happens in fact to the constants in
> the header I
> don't know (it requires a particular combination of digits for double
> rounding to be a problem), but it seems sensible to avoid the
> problem in
> the first place.
> BTW, in case you are wondering why this matters - imagine
> that we have set
> the hardware fpu to use float precision - in this case it's
> important that
> the number is stored as the nearest float representation, and
> not stored as
> a long double as this will get rounded again when loaded onto
> the stack -
> and not necessarily to the correct value.
> >[PAB] Not too sympathetic to dodgy compilers here!
> >Surely the above is strictly correct, and should not avoid
> any warnings.
> Actually, my point was that these "dodgy" compilers may
> result in a more
> correct value being loaded on the fpu stack, than those that enforce
> rounding to float.
> - John.
> --------------------------------------------------------------
> ------<e|-
> Attention online shoppers: Join beMANY! via the web and
> you'll start SAVING
> on all your long distance bills TODAY. Click for more!
> --------------------------------------------------------------
> ------|e>-

Boost list run by bdawes at, gregod at, cpdaniel at, john at