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_moses at mentor 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: Tue, 09 Apr 2013 10:43:47 -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> <5161FA1A dot 5060100 at redhat dot com> <51620F35 dot 5080101 at codesourcery dot com> <51634CA1 dot 4050006 at redhat dot com> <51636912 dot 10702 at codesourcery dot com> <5163710F dot 9080500 at mentor dot com>
On 04/08/2013 09:38 PM, Brooks Moses wrote:
> Which is to say that there's a more fundamental problem here, because
> there's no clear way to implement what you actually need to do in the
> test harness as it stands. This test suite is assuming (in, e.g.,
> check_float_internal) that some fixed multiple of ulp(expected) is a
> reasonable measure of the expected error bounds.
>
> That, in this case, is fundamentally _false_.
I understand your point about this now.
The error in expressing pi is simply an upper bound on the error.
It will generate many ulp error for a precise answer to the question
cos(M_PI_2l).
I think Rich's answer is the only reasonable one, which is to compute
what the exact answer should be.
Cheers,
Carlos.