Boost logo

Boost :

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:


> And Intel on Linux/IA64


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at