[Numpy-discussion] Test failures on FreeBSD buildbot

[Charles R Harris]

On Mon, Jul 27, 2009 at 10:16 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Charles R Harris wrote:
> >
> >
> > On Mon, Jul 27, 2009 at 9:37 PM, David Cournapeau <cournape at gmail.com
> > <mailto:cournape at gmail.com>> wrote:
> >
> >     On Tue, Jul 28, 2009 at 8:44 AM, Charles R
> >     Harris<charlesr.harris at gmail.com
> >     <mailto:charlesr.harris at gmail.com>> wrote:
> >
> >     > ERROR: test_nan_items (test_utils.TestApproxEqual)
> >     >
> >
> ----------------------------------------------------------------------
> >     > Traceback (most recent call last):
> >     >   File
> >     >
> >
> "/tmp/numpy-buildbot/b12/numpy-install/lib/python2.5/site-packages/numpy/testing/tests/test_utils.py",
> >     > line 248, in test_nan_items
> >     >
> >     >     self._assert_func(anan, anan)
> >     >   File
> >     >
> >
> "../numpy-install/lib/python2.5/site-packages/numpy/testing/utils.py",
> >     line
> >     > 433, in assert_approx_equal
> >     > ValueError: math domain error
> >     >
> >     >
> >
> ----------------------------------------------------------------------
> >     >
> >     > Ran 2177 tests in 30.179s
> >     >
> >     >
> >     > I expect there is a problem with the FreeBSD math libraries.
> >
> >     Actually, I am surprised it did not fail on Linux/Windows/Mac OS X :)
> >     Reading the code for assert_approx_equal, using log/pow functions
> >     nan should produce this error. I will work on a fix,
> >
> >
> > Yeah, the function is kind of a mess.
>
> Yes - I am afraid I have added to the mess with my nan/inf handling :( I
> tried reimplementing from a clean state, but quite a few unit tests
> depend on some 'obscure' features. For example, do we really want
> assert_array_equal(np.array([1, 1]), 1) to be true ? I understand it is
> handy, but it can hide bugs, and it makes writing the function more
> complicated (as you can't check that both arrays have the same shape,
> and covering every corner case with handling scalar/scalar arrays/arrays
> is difficult).
>
> I am also concerned with speed issues (they are likely to be a
> bottleneck in many unit tests).
>
> > I think most of the math can be avoided.
>
> Do you know of a way to avoid log/pow for approx equal ?
>

I'd just look at the difference and see if it exceeded some fraction of the
expected value. There is the problem of zero, which could be handled in the
usual way as diff < abserr + relerr. I think abserr would need to be a new
keyword with a default value. Since the relerr is specified by digits you
probably need 1/10**digits, but there should be no problem with that.
Really, only a multiplication should be needed to determine the precision to
x digits. Nan and +/- inf need to be special cased but I haven't thought
about that.

I agree that the broadcasting is both a convenience and a trap here, but its
probably a bit late to change that.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090727/7d49d71a/attachment.html>