Re: [PATCH] libm-test.inc: Correctly implement ulp().

[Andreas Jaeger <aj at suse dot com>]

On 05/17/2013 12:10 AM, Carlos O'Donell wrote:
> Joseph, Andreas,
>
> The following patch fixes the master TODO entry:
> ~~~
> When libm-test.inc computes ulps for a case where the
> expected result was 0, it computes them as if the expected
> result was 1, but should compute them more strictly, as
> if the expected result was subnormal.
> ~~~
>
> The current value used for ulp around zero is just wrong,
> and this test fixes it such that ulp(0) is the smallest subnormal
> value nearest to zero, which makes the most sense for testing
> values near zero.
>
> The patch causes 1 regressions for each of the types on x86-64,
> all having to do with " cpow (e + 0 i, 0 + 2 * M_PIl i) == 1.0 + 0.0 i".
>
> e.g.
> ~~~
> 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.


>   ulp       :  49574254330601946645624577457449570499924092730262502276699108050758815961872456534680590923878394894568106529394830647426366788862820389065085884559356492887832038112641869699009951764897429803306592466752526966543116836508033509283588356790340998671355914085615325047212736424084369897623125485610193649664.0000
>   max.ulp   :  2.0000
> Maximal error of real part of: cpow
>   is      : 2 ulp
>   accepted: 2 ulp
> Maximal error of imaginary part of: cpow
>   is      : 49574254330601946645624577457449570499924092730262502276699108050758815961872456534680590923878394894568106529394830647426366788862820389065085884559356492887832038112641869699009951764897429803306592466752526966543116836508033509283588356790340998671355914085615325047212736424084369897623125485610193649664 ulp
>   accepted: 2 ulp
>
> Test suite completed:
>    8044 test cases plus 7416 tests for exception flags executed.
>    2 errors occurred.
> ~~~
>
> I thought that perhaps I could use the same strategy as I had
> used with sincos to fix this failure, but I can't. Even correcting
> the answer for the approximation of e and 2 * M_PIl still results
> in an imaginary answer that is not near enough to zero.
>
> Instead as Joseph has suggested in the past I've disabled this
> test and indicated that it is because of BZ #14473:
> Bug 14473 - Inaccurate CPOW* function on all machines.
> http://sourceware.org/bugzilla/show_bug.cgi?id=14473
>
> No regressions on x86_64.
>
> OK to checkin?

> [...]
> @@ -6991,7 +7015,11 @@ cpow_test (void)
>     TEST_cc_c (cpow, 1, 0, 0, 0, 1.0, 0.0);
>     TEST_cc_c (cpow, 2, 0, 10, 0, 1024.0, 0.0);
>
> +  /* Disabled until we fix BZ #14473 */

Add a "." and two spaces as usual here.

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?

Thanks for the patch,
Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126