
Boost : 
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 20000727 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.
Thanks
Paul
> 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!
> http://click.egroups.com/1/6594/4/_/9351/_/964611902/
> 
> e>
>
>
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk