This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH COMMITTED] Regenerate sparc ULPs.
- From: David Miller <davem at davemloft dot net>
- To: joseph at codesourcery dot com
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 23 Apr 2014 13:03:06 -0400 (EDT)
- Subject: Re: [PATCH COMMITTED] Regenerate sparc ULPs.
- Authentication-results: sourceware.org; auth=none
- References: <20140413 dot 231141 dot 1503644473158925927 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1404231449080 dot 13425 at digraph dot polyomino dot org dot uk>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Wed, 23 Apr 2014 14:51:09 +0000
> On Sun, 13 Apr 2014, David Miller wrote:
>
>> For example, for test-float and test-ifloat y1_upward gets a ULP of 10,
>> and for test-ldouble and test-ildoubl y1_upward gets a ULP of 10 and
>> y1_downward gets a ULP of 13.
>>
>> I see that we use an upper limit of 13 for IBM long double in the
>> inexact cases... should we use something similar for 128-bit IEEE
>> cases as well?
>
> No. That increased limit is an allowance for IBM long double not being an
> IEEE type and the underlying arithmetic operations having errors of up to
> 3 ulps. If you get larger errors for an IEEE type, the implementations of
> the relevant libm functions should be fixed to reduce error accumulation.
Ok, right now it's just y1_upward() giving me an error of 10 ULPs for
float.