Re: [Boost-bugs] [Boost C++ Libraries] #6975: lexical_cast<double> produces different answers with 53-bit FPU precision

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6975: lexical_cast<double> produces different answers with 53-bit FPU precision
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-07-24 18:36:19

#6975: lexical_cast<double> produces different answers with 53-bit FPU precision
------------------------------------------------------------+---------------
  Reporter:  Jonathan Jones <jonathan.jones@…>              |       Owner:  apolukhin   
      Type:  Support Requests                               |      Status:  assigned    
 Milestone:  To Be Determined                               |   Component:  lexical_cast
   Version:  Boost 1.49.0                                   |    Severity:  Cosmetic    
Resolution:                                                 |    Keywords:              
------------------------------------------------------------+---------------

Comment (by Jonathan Jones <jonathan.jones@…>):

 Replying to [comment:1 apolukhin]:
 > This issue won't be fixed in nearest future (it shall be fixed in ticket
 #5660)


 Do you have a rough estimate of the timeframe in which it will be fixed?


 > When casting to doubles, lexical_cast uses long doubles for getting
 better precision and assumes that long doubles precision set to 64
 (default).
 > But even with 53bit precision result is accurate enougth, so this bug is
 not critical.


 It's the double->string->double issue, as mentioned in ticket #5660, which
 is problematic for us.  Doubles which should be serializable to a string
 and back to a double with no change are returning slightly different
 answers from the original double.


 > By the way: you shall not compare floats using == and != operatos.
 > See http://www.parashift.com/c++-faq-lite/floating-point-arith.html



 I understand that this is true in the general case, but in our case the
 floats we are comparing are pre-calculated numbers which are exactly
 representable (not approximated) in floating point.

 FWIW, we've worked around the problem by forcing lexical_cast to always
 use:

     float_types_converter_internal(T& output, int /*tag*/)

 which doesn't seem to suffer from the same issue.  It's only
 lcast_ret_float<Traits> which has the problem.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6975#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.