Proposed resolution:

Change [facet.num.put.virtuals], Stage 1, under p5 (near the end of Stage 1):

For conversion from a floating-point type, str.precision() is specified as precision in the conversion specification if floatfield != (ios_base::fixed | ios_base::scientific), else no precision is specified.

[ 2009-10 Santa Cruz: ]

Move to Ready.

[ 2009-07 Frankfurt ]

Leave this open for Robert and Daniel to work on.

Straw poll: Disposition?

• Default is %.6a (i.e. NAD): 2
• Always %a (no precision): 6
• precision(-1) == %a: 3

Daniel and Robert have direction to write up wording for the "always %a" solution.

2009-07-15 Robert provided wording.

[ Howard: I think the fundamental issue we overlooked was that with %f, %e, %g, the default precision was always 6. With %a the default precision is not 6, it is infinity. So for the first time, we need to distinguish between the default value of precision, and the precision value 6. ]

I am trying to understand how TR1 supports hex float (%a) output.

As far as I can tell, it does so via the following:

8.15 Additions to header <locale> [tr.c99.locale]

In subclause [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line:
floatfield == ios_base::scientific %E

add the two lines:

floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
floatfield == ios_base::fixed | ios_base::scientific %A 2

[Note: The additional requirements on print and scan functions, later in this clause, ensure that the print functions generate hexadecimal floating-point fields with a %a or %A conversion specifier, and that the scan functions match hexadecimal floating-point fields with a %g conversion specifier. end note]

Following the thread, in [facet.num.put.virtuals], we find:

For conversion from a floating-point type, if (flags & fixed) != 0 or if str.precision() > 0, then str.precision() is specified in the conversion specification.

This would seem to imply that when floatfield == fixed|scientific, the precision of the conversion specifier is to be taken from str.precision(). Is this really what's intended? I sincerely hope that I'm either missing something or this is an oversight. Please tell me that the committee did not intend to mandate that hex floats (and doubles) should by default be printed as if by %.6a.