Re: libm-test.inc: Computing ulps near FP_ZERO.

[Brooks Moses <brooks at codesourcery dot com>]

Carlos O'Donell wrote, at 4/7/2013 3:58 PM:
> Excellent discussion. 

Thanks!  Glad it was helpful.

> At this point I'm in agreement with you.
> 
> The likely course of action is to do the following:
> 
> (a) Adjust tests that rely on accurate input to generate accurate
>     output, such as the cos(pi/2) test. These tests will have their
>     expected result adjusted by the error involved in converting
>     their input argument.
> 
> (b) Enhance algorithms to detect zero branches. In particular fix
>     cpow to detect zero branches. We have a microbenchmark framework
>     now so I could run the new algorithms through that to see if
>     the function is faster or slower.
> 
> Comments?

FWIW, that sounds reasonable to me, but I'm just the peanut gallery.  :)

I'd be interested in knowing how the microbenchmarks come out.  My guess
is that adding check for zero-branches (which you'd implement just by
checking for imag(z)==0, and then do other stuff only if that's true)
will be negligible cost on most architectures with branch prediction.
And my suggested alternate implementation might be faster, because
you're avoiding some trigonometric calls.

> What about the cases where we can't easily fix the algorithm to
> detect the zero branches? What do we use for ulp(0x0.0p0) then? :-)

I figure those fall into three categories:

 * You're getting zero through something that amounts to subtracting
   two "equal" quantities (in the above cases, that was a pi/2 input
   and a pi/2 used to condition the input, basically), and the
   expected error is based on ulp(input), not ulp(output).

 * A zero input propagates through to a zero output.  Here, you ought
   to get exactly zero in the output.  This is what happened in the
   algorithm I wrote out for w^z; it doesn't actually detect zeros in
   a branching sense, but will preserve them nonetheless.

 * A zero output results from underflow.  Here you also ought to get
   exactly zero.

Are there any cases in the testsuite that are exceptions to this
categorization?

I think anything where you can't get an exact zero is going to end up
being like the w^z-with-the-current-implementation case -- where the
error is inherently on the order of ulp(1) or so, and the best the test
can do is document why -- rather than giving you an error on the order
of the smallest floating-point numbers.

- Brooks