Re: [Boost-users] [Interval] Help debugging compiler optimization

Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
From: degski (degski_at_[hidden])
Date: 2018-03-08 13:02:58

On 8 March 2018 at 02:36, Tim van Erven via Boost-users <
boost-users_at_[hidden]> wrote:

> My (somewhat naive) view of compilers is that they can only do
> optimization that has no visible effects on the behavior of the program.
>

Here is what the different floating point behaviors (strict/fast/precise)
mean with VC (I realize you're on linux, but the same must count/exist on
linux as these are CPU features). As you can see, it's intricate.

In general what you are trying to do is not possible (that way), you'll
need to allow for some delta between values that if the difference is
smaller that delta, this qualifies them as being equal. So far so good so.
We have our friends FLT_EPSILON and DBL_EPSILON from the STL
<http://en.cppreference.com/w/cpp/types/climits>. These don't help you
much, the delta defined by those two is the difference between 2
consecutive floats on the interval from 1. to 2.. So towards 0., the
EPSILON is getting smaller, over 2. it's getting bigger, suggesting
different approaches are needed for different parts of the real numbers
line.

Daniel Lemire
<https://lemire.me/blog/2017/02/28/how-many-floating-point-numbers-are-in-the-interval-01/>
has written about this subject and has suggested solutions in the past
(search the blog for more articles pertaining to this subject), for only to
(partially) revert those opinions later. It's quite a problem really. In
case you are really working with fractions (as in your example 3 * (1/3)),
it would be better to use a fractions library.

The above assumes IEEE754 floating point numbers
<https://en.wikipedia.org/wiki/Floating-point_arithmetic#IEEE_754:_floating_point_in_modern_computers>
.

degski