Re: [Boost-bugs] [Boost C++ Libraries] #12527: cpp_bin_float: Anal fixation. Part 3. Double rounding when result of convert_to<double>() is a subnormal

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #12527: cpp_bin_float: Anal fixation. Part 3. Double rounding when result of convert_to<double>() is a subnormal
Date: 2016-11-07 00:46:18

#12527: cpp_bin_float: Anal fixation. Part 3. Double rounding when result of
convert_to<double>() is a subnormal
-------------------------------+----------------------------
Reporter: Michael Shatz | Owner: johnmaddock
Type: Bugs | Status: closed
Milestone: To Be Determined | Component: multiprecision
Version: Boost 1.62.0 | Severity: Problem
Resolution: fixed | Keywords:
-------------------------------+----------------------------

Comment (by Michael Shatz):

> I was about to say that it's a non-issue because things that return zero
are handled separately. However, there was a bug in that (separate) case,
see

I think, you didn't understand my case.

If I correctly understood the voodoo of numeric_limits, your condition
if(e < min_exp_limit) is the same as if (x.backend().exponent() < -1077).

But the case that I am talking about happens when (x.backend().exponent()
== -1075) for the smallest absolute value in this range.
The rest of the range is rounded away from zero, i.e. to smallest negative
number == -(2!**-1074), but this single point on the edge of the range, is
a tie, and as a good tie it has to be rounded to nearest even, i.e. to
negative zero.
However my original workaround rounds this point to positive zero. It
happens due to same IEEE rule that we discussed few weeks ago - difference
of equals numbers is always a positive zero.

That's why a new workaround is better than the original and why any change
of min_exp_limit would not help this particular unique point.

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

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:20 UTC