From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-06-25 02:58:35
On Sun, 22 Jun 2003, Paul A Bristow wrote:
> | Consequently, more than one constant out of 10000 may suffer
> | from this problem. So it is rare, but it is not impossible.
> | It's why I was suggesting that a library should provide a
> | mean to know if a number representing a constant is the
> | nearest or not.
> One constant out of 10000 seems a rather small risk.
> Can't we just check that all the constants we offer are in fact the
> Since very few contain many zeros, I think I am prepared to wager a few
> beers on this one!
> So does this mean that the presentation function will use the 'exactly
> representable' decimal digits appropriate for the floating point format
> (choice of 5) and for the FP type float, double, long double to give to
> the compiler to use?
Sorry, I'm not sure I clearly understand what you mean. What I would do is
float the_constant_f = ... /* a 24 binary digits representation */;
double the_constant_d = ... /* a 53 binary digits representation */;
long double the_constant_ld =
... /* a 64 binary digits representation */;
... /* a 102 binary digits representation */;
#else /* we don't know this floating-point format */
... /* a 40 decimal digits approximation */;
/* And then there would be all the wrappers... */
The binary representations will be exact values in order to avoid compiler
rounding. So all possible floating-point formats should be thought of.
However, if one of them is missing, we fall back on a common 40 decimal
digits constant. Since we can't be sure there won't be any rounding
problem, we flag the result as being "maybe inaccurate". Does it make
> PS How do we check? Does it depend on the FP format?
It depends on the source FP format and on the destination FP format. We
check it by looking if the rounded down version of the most precise value
is equal to the less precise version of the constant.
But it doesn't matter anymore if we explicitely give the values of the
constant for all the formats and not only for the most precise format.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk