
Boost : 
Subject: Re: [boost] [math] boost::math::isfinite fails with fastmath
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 20121126 09:47:38
> Original Message
> From: boostbounces_at_[hidden] [mailto:boostbounces_at_[hidden]] On Behalf Of Gaetano
> Mendola
> Sent: Monday, November 26, 2012 1:34 PM
> To: boost_at_[hidden]
> Cc: John Maddock
> Subject: Re: [boost] [math] boost::math::isfinite fails with fastmath
>
> On 11/26/2012 02:13 PM, John Maddock wrote:
> >> I'm wandering if this is to be expected, the following code fails if
> >> compiled with fastmath:
> >>
> >> //====================================================
> >> #include <boost/math/special_functions/fpclassify.hpp>
> >> int main() {
> >> const float a = 0.0f/0.0f;
> >> assert(not boost::math::isfinite(a)); }
> >
> > Which fails  does the 0/0 actually yield an infinity? Or is it isfinite that fails?
> >
> > Either way is hard to make guarentees once you enable an option like that.
>
> The following code:
>
> #include <boost/math/special_functions/fpclassify.hpp>
> int main() {
> const float a = 0.0f/0.0f;
> std::cout << "a => " << a << std::endl;
> std::cout << "boost::math::isfinite(a) => " << boost::math::isfinite(a) << std::endl;
> std::cout << "a != a: " << (a!=a ? "true" : "false") << std::endl; }
>
> gives:
>
> a => nan
> boost::math::isfinite(a) => 1
> a != a: true
This appears to perhaps not conform to this
ffinitemathonly, <<<<<<<<<<<< so the IEEE pattern for infinity (or NaN?) will never be set.
"
ffastmath
Sets fnomatherrno, funsafemathoptimizations, fnotrappingmath,
ffinitemathonly, <<<<<<<<<<<< so the IEEE pattern for infinity will never be set.
fnoroundingmath,
fnosignalingnans
Or does this mean quiet NaNs *are* supported?
And do the specific tests boost::math:: isnan and isinf help you any more? (They shouldn't, I
think).
Can you achieve what you want (funsafemathoptimizations for speed ?) by specifying individual
options?
And provide some test cases and raise a Trac ticket (No promises  the logic is more than byzantine
enough already).
Paul
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk