This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libm-test.inc: Computing ulps near FP_ZERO.


On 04/08/2013 09:04 PM, Brooks Moses wrote:
> Carlos O'Donell wrote, at 4/8/2013 4:02 PM:
>> Regenerating ULPs for /home/carlos/build/glibc/math/test-idouble
>> testing double (inline functions)
>> Failure: Test: cos (pi/2) == PI_ERROR/2
>> Result:
>>  is:          6.12323399573676603587e-17   0x1.1a62633145c070000000p-54
>>  should be:   1.11022302462515654042e-16   0x1.00000000000000000000p-53
>>  difference:  4.97899625051479936837e-17   0x1.cb3b399d747f20000000p-55
>>  ulp(x)    :  2.46519032881566189191e-32   0x1.00000000000000000000p-105
>>  ulp       :  2019720827359740.5000
>>  max.ulp   :  0.0000
> 
> I think you've missed the bit where I pointed out that the expected
> result here is "0 +/- ulp(pi/2)/2", not "ulp(pi/2)/2"!

Only if you don't know the error apriori.

I just resolved the error for a known implementation of an IEEE754 type.

> In other words, you've confused the expected error bound with the
> expected result.

We know the exact value of M_PI_2l and we can say if the error will be
positive or negative.

In the case of a 64-bit double I know the error to be in the positive
direction so the answer is "0 + ulp(pi/2)/2" or "ulp(pi/2)/2".

Does that make sense?

It works around the limitation in the test suite to express answers
as bounds, and technically ulp as a bound of ulps.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]