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

Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
From: Mário Costa (mario.silva.costa_at_[hidden])
Date: 2018-03-07 14:53:44

Not sure this "random" aswer explains it:

1/3 it's a recurring decimal (https://en.wikipedia.org/
wiki/Repeating_decimal), that means it is not possible to represent it
within a limited number of bits (even in 64 bits).

So your "bug" example, I would say that it's not a bug. Using optimization
in one of the cases the compiler can figure out, that the value is 1, by
analyzing constant values assigned to v2 and lazy expanding the expression
(template expansions, etc), (which is correct math value).
The other option v1, uses memory storage, and because of that, it cannot
lazy expand the expression at the function call, so because you cannot
store 1/3 perfectly in 64 bits, after multiplying it, it always results in
a number lower 1.

On Wed, Mar 7, 2018 at 11:54 AM, degski via Boost-users <
boost-users_at_[hidden]> wrote:

> On 6 March 2018 at 20:43, Nathan Ernst via Boost-users <
> boost-users_at_[hidden]> wrote:
>
>> This does feel like a floating-point optimization switch, though, at
>> least to me.
>>
>
> Additionally, the optimization level it self could interfere with the
> order of calculation, leading to possibly different results.
>
> degski
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>