This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm-test.inc: Computing ulps near FP_ZERO.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Brooks Moses <brooks at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Jaeger <aj at suse dot com>, Thomas Schwinge <thomas at codesourcery dot com>, David Miller <davem at davemloft dot net>
- Date: Sun, 07 Apr 2013 18:58:34 -0400
- Subject: Re: libm-test.inc: Computing ulps near FP_ZERO.
- References: <51606D8A dot 9080003 at redhat dot com> <5160A4D7 dot 9080802 at codesourcery dot com> <516183BD dot 6060700 at redhat dot com> <5161AADF dot 2040403 at codesourcery dot com>
On 04/07/2013 01:20 PM, Brooks Moses wrote:
>> We are back to this:
>>
>> java says ulp(0x0.0p0) is 0x0.0p-1022, which is the next step to
>> a normal fp value.
>>
>> I expected ulp(0x0.0p0) to be 0x0.0p-1074, which is the next step
>> to the smallest subnormal fp value.
>
> ...and neither of those represent a likely error magnitude for the w^z
> computation.
Excellent discussion.
At this point I'm in agreement with you.
The likely course of action is to do the following:
(a) Adjust tests that rely on accurate input to generate accurate
output, such as the cos(pi/2) test. These tests will have their
expected result adjusted by the error involved in converting
their input argument.
(b) Enhance algorithms to detect zero branches. In particular fix
cpow to detect zero branches. We have a microbenchmark framework
now so I could run the new algorithms through that to see if
the function is faster or slower.
Comments?
What about the cases where we can't easily fix the algorithm to
detect the zero branches? What do we use for ulp(0x0.0p0) then? :-)
Cheers,
Carlos.