14220 – [3.5] num_put::do_put() undesired float/double behavior (original) (raw)

When a float or double is streamed to output in fixed-point format, rounding up occurs well before the precision specified by the stream.

5.55555555e-17, when streamed to a stream with the scientific flag set and a precision of 25 will print 5.55555555[#'s-up-to-20]e-17. When streamed with the fixed flag set, it will print out 0.0000000000000000560000000. If the number is especially small (e-20+), it will print out as all zeroes.

I looked at the code in 3.2.3 and 3.4 versions of g++, and saw that it was because the max_digits is being set from the numeric_limits::digits10 field. The precision is then set to be less than or equal to the max_digits. So on my platform, where digits10 is 16 (+2), the precision will get set to 18, max. That works fine for scientific values, but I would argue that if I ask a stream for 25 places of precision, and put a float/double into it that should be represented by 0.0000000000000000555555555, that I would see that value, not a rounded version.

My understanding is that the numeric_limits::digits10 value for a float/double amounts to the significant digits if it were in scientific notation. If that is the case, then the max_digits for fixed number would be digits10 + the number of preceding zeroes, which is probably max_exponent10.

This was seen on Solaris 8 and Irix 6.5.22.

Comment 1 Paolo Carlini 2004-02-20 12:11:22 UTC

Confirmed. Actually, basing on the standard (22.2.2.2.2, p8-11-13), I think that simply the precision passed down to the printing code must not be clipped at all.

Comment 5 Paolo Carlini 2004-04-15 19:39:33 UTC

*** Bug 14969 has been marked as a duplicate of this bug. ***

Comment 7 Mark Mitchell 2004-06-12 22:57:49 UTC

Marked as 3.5 only, so retargeting at 3.5.0.

Comment 8 Paolo Carlini 2004-06-13 08:34:14 UTC

Actually, this is already fixed for 3.4.1. I want to put the fix on hold for 3.5 only because with Benjamin we have a plan to branch a separate 7.0 branch where a pending invasive patch will interfere with this fix...

Comment 9 Mark Mitchell 2004-06-18 23:55:20 UTC

Really retargeting at 3.5.0 this time.

Comment 11 Paolo Carlini 2004-07-29 22:14:23 UTC

Fixed everywhere.