Strange bug may be associated with rounded_transc_opp policy

[Vitor Vieira Lopes <vitor.lopes@…>]

When I evaluate the following expression: a = Interval(1.0, 3.0)
exp( a * log(0.001) )

I receive the result [nan ~ nan] when I select the rounded_transc_opp policy. However, if I select the rounded_transc_exact all goes well and I receive the expected result: [1E-9 ~ 0.001]

If I select the rounded_transc_opp policy and evaluate the expression:
exp( a * log(0.0001) ) all works well and I receive the expected result: [1E-12 ~ 0.0001] also works well for:
exp( a * log(0.0011) ) but not with:
exp( a * log(0.00101) )

I hope that someone can look at this problem, since this is really a very strange situation.

Keep up with this excellent work and best regards...

Vitor

[Steven Watanabe]

According to the documentation:

The classes rounded_transc_exact, rounded_transc_std and rounded_transc_opp expect the std namespace to provide the functions exp log cos tan acos asin atan cosh sinh tanh acosh asinh atanh. For the _std and _opp versions, all these functions should respect the current rounding mode fixed by a call to downward or upward.

Please note: Unfortunately, the latter is rarely the case....

[Vitor Vieira Lopes <vitor.lopes@…>]

Replying to steven_watanabe:

According to the documentation:

The classes rounded_transc_exact, rounded_transc_std and rounded_transc_opp expect the std namespace to provide the functions exp log cos tan acos asin atan cosh sinh tanh acosh asinh atanh. For the _std and _opp versions, all these functions should respect the current rounding mode fixed by a call to downward or upward.

Please note: Unfortunately, the latter is rarely the case....

But how this can account for the apparently inconsistent behavior? Note that for some values I do not have any problem when I use the _opp version while others are problematic. In the examples, the value 0.0011 works well but 0.001 does not. It seems to me that this should not present any type of numerical issue due to the values involved.

[smr@…]

Seems to still be a problem in Boost 1.42: see the report from Debian: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584325

[smr@…]

By the way, the Debian user reports that his code does work as expected on 32 bits, but fails on 64 bits.