C++ Standard provides numeric_limits::digits10 which tell the number of
decimal digits guaranteed to be correct on output,
for example for real or floating point types float, double and long double.

However, it does not tell you how many digits are required to fully specify
a real value ON INPUT.

You need a few MORE than digits10 (which is the lower number below, for
example 15 for double)
for example for double you need 17 for input, two more than digits10, which
is the number guaranteed to be correct on output (15).

This is described fully by William Kahan ('father'of IEEE 754) in his report
on the status of IEEE754 in 1996.

http://http.cs.berkley.edu/~wkahan/ieee754status/ieee754.ps page 4 gives
significant digits for real formats.

He gives two significant digits values for each of the three real formats :

"
The lower value is at least floor((n - 1) * log10(2)  significant digits,
and the upper, ceil(1 + n * log10(2))  significant digits,
where n is number of significand bits.
For float, floor (24 -1) * 0.301  =  6 &  <<<<<<<< digits10 correct for
output
               ceil(1 + 24 * 0.301)     =  9, <<<<<<<<<< needed for input
& for double 15 and 17, extended (long double?) 18 & 21, quadruple 33 & 36).
For example, for float:

If a decimal string with at most the lower significant digits (6) is
converted to float precision and the converted back to the same number of
significant digits (6), then the string should match the original 6 digits.
If a float value is converted to a decimal string with at least the upper
number of significant digits (9), and then converted back to float, then the
final number must match the original float number.
Note the asymmetry. The upper is the number of significant digits required
for input, the lower is number guaranteed on output.
"

The existing std::numeric_limits::digits10 gives the lower value floor
(24 -1) * 0.301)

I propose an addition to numeric_limits to provide the upper value ceil(1 +
n * 0.301)
perhaps calling it std::numeric_limits::input_digits10 unless you have a
better suggestion?

There should be no problems with implementation and portability
since it is only a very simple function of the number of bits used for the
significand.

This will help to avoid me (and others!) being confused in future!

Paul
--
Paul A. Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria LA8 8AB
+44 1539 56 18 30
mailto: pbristow@hetp.u-net.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]