Boost C++ Libraries: Ticket #6975: lexical_cast produces different answers with 53-bit FPU precision

attachment set

Fri, 08 Jun 2012 21:45:31 GMT

attachment → lexical_cast.cpp

status, type, severity changed

Antony Polukhin — Tue, 24 Jul 2012 18:12:05 GMT

status new → assigned
type Bugs → Support Requests
severity Problem → Cosmetic

This issue won't be fixed in nearest future (it shall be fixed in ticket #5660) 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.

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

Tue, 24 Jul 2012 18:36:19 GMT

Replying to 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.

Antony Polukhin — Tue, 24 Jul 2012 20:17:53 GMT

Replying to Jonathan Jones <jonathan.jones@…>:

Replying to 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?

I do not think that it would be fixed in nearest two releases of boost.

<snip>

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.

It is good enough solution, but it may also return slightly different answers for some numbers on MSVC, older versions of GCC and non popular compilers. And this solution is slightly slower (but I do not think that you will notice it)

status, milestone changed; resolution set

Antony Polukhin — Mon, 09 Mar 2015 09:36:23 GMT

status assigned → closed
resolution → fixed
milestone To Be Determined → Boost 1.58.0

Since Boost 1.58 lexical_cast must use converters from Standard Library, so that issue must be already resolved on Standard Library level.