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