This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: pi/2 again...
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Thu, 02 May 2013 21:28:39 -0400
- Subject: Re: pi/2 again...
- References: <20130502 dot 152322 dot 1341414586375955556 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1305022015520 dot 12072 at digraph dot polyomino dot org dot uk> <20130502 dot 163507 dot 296024282119261738 dot davem at davemloft dot net>
On 05/02/2013 04:35 PM, David Miller wrote:
> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Thu, 2 May 2013 20:21:37 +0000
>
>> pi/2 rounded to nearest for ldbl-128 is
>> 0x1.921fb54442d18469898cc51701b8p+0L (computed with MPFR). The cosine of
>> that value, again rounded to nearest, is
>> 0x3.9a252049c1114cf98e804177d4c8p-116L.
>>
>> That cosine is exactly the value currently expected in libm-test.inc (but
>> MPFR prefers a different exponent when displaying it). If M_PI_2l, shown
>> as a hex float, is equal to the value given above, then you have a problem
>> with the ldbl-128 cos function being inaccurate near pi/2 (maybe a range
>> reduction issue) - which will need filing as such in Bugzilla and fixing.
>
> M_PI_2l is printed as a hex float equal to the value above so it's a cos()
> issue, bugzilla filed.
David,
Sorry that I didn't do this for all the arches when I updated libm-test.inc
to contain the correct answer for cos(pi/2). I figured that my changes were
strictly correct and that was we updated ulps we'd have to file bugs.
Joseph,
Given our discussion on policy about testing something that is known broken,
does this mean we should disable cos(pi/2) tests for 128-bit long double?
Cheers,
Carlos.