Re: [boost] Report from Berlin C++ Standards Committee meeting

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 
| floats/doubles
| <-> 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.

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=7
bf2f26d-171f-41fe-be05-4169a54eef9e

My new bug report on doubles:

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=F
DBK48810
 
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.
Similarly infinities.

http://article.gmane.org/gmane.comp.lib.boost.devel/134569/match=serializati
on+nan 

But simple 

        stream << output_value; // write out.
        double read_value;
        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
OK.

so I presume others do.

Paul

-- 
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
Phone and SMS text [phone], Mobile and SMS text [phone]
mailto: pbristow_at_[hidden]  http://www.hetp.u-net.com/index.html
http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html