RE: [boost] math constants

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.

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>-
>
>
>
>
>