From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-04-19 13:31:14
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
| Sent: 10 April 2006 16:51
| To: boost_at_[hidden]
| Subject: Re: [boost] Report from Berlin C++ Standards
| Committee meeting
| There are TWO issues which prevent perfect round tripping of
| <-> strings.
| a) correct number of digits and correct rendering/round
| tripping of floating point values
| b) portable rendering of the variety of Nans.
| Both of these issues have been discussed extensively on this
| list - without
| any resolution. I would think that resolving these issues is
| very important and long overdue.
Agree - it doesn't seem to be 'rocket science' - and yet it could come round
and bite - as one user has discovered recently.
Acceptance of the max_digits10 proposal should fix the coding problem.
(I am revising the document a little in the light on comments from C experts
in WG14 and will post a link when done).
I think we now have a reasonable idea of how to test round-tripping.
But some problems highlighted are up to Microsoft (and perhaps others too)
to fix -
Previous bug report for round-tripping floats - now works perfectly.
My new bug report on doubles:
Holding breath not recommended ;-)
It seems reasonable for the LWG to increase expectations in REQUIRING
round-tripping to work exactly - the Standard is not quite explicit on this.
Is a defect report the way to improve this?
So a) is in principle fixed IMO.
As to b), I had understood that we had agreed that all NaNs could reasonably
be treated as identical and one would get a NaN (unspecified) back.
stream << output_value; // write out.
stream >> read_value; // read back.
doesn't work for
double output_value = numeric_limits<double>::quiet_NaN(); // output_value
1.#QNAN != read_value 1
double output_value = numeric_limits<double>::infinity(); // output_value
1.#INF != read_value 1
So some special flag would be needed to hold the Nan or Inf nature.
If only there was a Standard representation of Nan and Infs. VERY
shortsighted, making NaNs and infs hardly useable.
Should we make a proposal for this for C++0x? So that the problem can at
least be solved eventually?
John Maddock's hex proposal is starting to sound MUCH more attractive!
It isn't portable, but no FP ever is, and in practice most people are using
32-bit floats or 64-bit doubles, or could do.
I was unsure whether there is a problem with denormalized values?
double output_value = numeric_limits<double>::denorm_min(); // round-trips
so I presume others do.
-- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow_at_[hidden] http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk