Re: test failure for mappers.cc

[Ben Abbott]

On Nov 10, 2010, at 1:42 AM, John W. Eaton wrote:

> On  9-Nov-2010, Ben Abbott wrote:
> 
> | I'm seeing the failure below with tip 11212
> | 
> |     octave:2> test mappers.cc
> |       ***** assert(arg (single(-1)), single(pi));
> |     !!!!! test failed
> |     assert (arg (single (-1)),single (pi)) expected
> |      3.1416
> |     but got
> |      3.1416
> |     values do not match
> | 
> | The difference between the actual and expected is ...
> | 
> |     arg (single (-1)) - single (pi)
> |     ans = -2.3842e-07
> | 
> | I consistently get the *exactly* same difference.
> | 
> |     for n = 1:10
> |       d(n) = arg (single (-1)) - single (pi);
> |     endfor
> |     std (d)
> |     ans = 0
> | 
> | I assume this came about after your mapper changesets. Do you
> | (anyone?) see this as well?
> 
> I'm not seeing the difference, but it is probably happening because I
> changed the float version of arg from
> 
>  float arg (float x) { return atan2 (0.0, x); }
> 
> to
> 
>  float arg (float x) { return atan2f (0.0f, x); }
> 
> It looks like your result is now off by about "2*eps ('single')".

You are correct.

octave:4> arg (single (-1)) - single (pi) + 2 * eps ("single")
ans = 0

> Does adding that as a tolerance avoid the warning?  Even if it does,
> should we make the change?  Shouldn't the atan2f function in your math
> library recognize -1 as a special case and return precisely the single
> precision value for pi?  Should we be tweaking test tolerances to hide
> what might be considered bugs in system libraries?
> 
> jwe

I agree with Michael, and don't think a tolerance should be used here.

If you (anyone?) can tell me which library is responsible I'll take a look at 
Apple's changes to the gcc sources. If I can find the place to go, I'll file a 
bug report as well.

Ben