This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] libm-test.inc: Correctly implement ulp().
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 17 May 2013 15:18:41 -0400
- Subject: Re: [PATCH] libm-test.inc: Correctly implement ulp().
- References: <5195593A dot 7090202 at redhat dot com> <51968072 dot 2090606 at suse dot com>
On 05/17/2013 03:09 PM, Andreas Jaeger wrote:
>> Regenerating ULPs for /home/carlos/build/glibc/math/test-double
>> testing double (without inline functions)
>> Failure: Test: Imaginary part of: cpow (e + 0 i, 0 + 2 * M_PIl i) == 1.0 + 0.0 i
>> Result:
>> is: -2.44929359829470641435e-16 -0x1.1a62633145c070000000p-52
>> should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
>> difference: 2.44929359829470641435e-16 0x1.1a62633145c070000000p-52
>> ulp(x) : 4.94065645841246544177e-324 0x0.00000000000010000000p-1022
>
> While I understand why you print this out for explanation, I consider
> this more a debugging output and propose to not output "ulp(x)" at
> all, I fear it confuses only.
I'm happy to remove it if people think it's just clutter.
I will assume that you suggest I remove it :-)
I'll wait to see what others have to say and if they think
it useful or just clutter and debugging.
>> + /* Disabled until we fix BZ #14473 */
>
> Add a "." and two spaces as usual here.
Fixed.
> Besides the two issues, this looks fine. I suggest to give others two
> more days to review this, I would love to see Joseph's comments here.
> If there are no further comments, I would consider it fine.
>
> Does this change mean we should regenerate the ULPs for all
> architectures from scratch?
As part of the final 2.18 release process everyone should be
regenerating ulps from scratch.
This patch didn't change anything except for the one cpow
case on x86_64 where it exposed the inaccuracies of the
complex functions (which we already knew).
Cheers,
Carlos.