Re: [boost] Optimized portable isnan, isfinite, fpclassify etc

From: Johan Råde (rade_at_[hidden])
Date: 2006-11-10 07:59:39

John Maddock wrote:
> Johan Råde wrote:

>> Win32 / Intel 7.? / ia32
>>
>>   where: basic_test<float> line 242
>>   what: !isinf(signalling_NaN())
>>   why: broken numeric_limits<T>::signaling_NaN

> Not sure about that: the std lib is the same as that used by VC6, however 
> these are both old compilers now, so maybe ignor this one for now (your code 
> doesn't compile on VC6 anyway).

I'm quite sure.
Which of the following two facts are you not sure about? ;-)

Fact 1: numeric_limits<float>::signaling_NaN on Win32/Intel 7/ia32 
returns a number with binary expansion ff 80 00 00

Fact 2: Under the IEEE754 standard, ff 80 00 00 is the binary expansion 
of single precision negative infinity.

I will disable the signaling_NaN tests on Intel <= 7.

>> HP-UX / aCC / ia64
>>
>>   where: basic_test<float> line 122
>>   what: fpclassify(-denorm_min()) == FP_SUBNORMAL
>>   why: multiple definitions of FP_SUBNORMAL ?
> 
> I suspect that the negation of the denorm causes it to round down to zero maybe?

I agree.
Your suggestion 4 below should take care of that.

> 
>> Linux / Intel 9.1 / ia64
>>
>>   where: basic_test<float> line 139
>>   what: fpclassify(min()/2) == FP_SUBNORMAL
>>   why: broken numeric_limits<T>::min ?
>  
> My suspicion would be that:
> 
>         x = (std::numeric_limits<T>::min)() / 2;
> 
> either underflows to zero, or is evaluated by the compiler at compile time 
> maybe?

I agree.
Your suggestion 4 below should take care of that.

>> Could you run the inspect tool on the last two platforms as well?
> 
> Here's HP-UX:

[snip]

> And Intel on Linux/IA64

[snip]

The results are as expected.

> Can I make a couple of suggestions with respect to your test program?
> 
> 1)  It would be useful if the asserts were changed to something that didn't 
> abort so we could see all the possible failures at once.
> 2) It would be useful if failed tests printed out the binary representation 
> of the failed value (merge the inspect tool into the test.
> 3) It would help to check whether numeric_limits::has_infinity/has_denorm 
> etc is true before testing those features.
> 4) It might pay to sanity check that denorm test values aren't zero or >= 
> numeric_limits<>::min() before using them.  That would catch out clever 
> compilers right away: there's no point in testing for a denorm if the value 
> isn't a denorm! :-)

I agree with all 4 suggestions.
And time spent building good tools usually pays off.

I will do 3 and 4, and add -denorm_min and min/2 to the inspect tool today.

I will do 1 and 2 later.

--Johan