[Numpy-discussion] Test fails for rev. 2473

Tim Hochberg tim.hochberg at cox.net
Wed May 3 10:00:13 EDT 2006


Albert Strasheim wrote:

>Hello Tim
>
>  
>
>>-----Original Message-----
>>From: Tim Hochberg [mailto:tim.hochberg at cox.net]
>>Sent: 03 May 2006 18:21
>>To: Albert Strasheim
>>Cc: numpy-discussion at lists.sourceforge.net
>>Subject: Re: [Numpy-discussion] Test fails for rev. 2473
>>
>>Albert Strasheim wrote:
>>    
>>
>
><snip>
>
>  
>
>>>I prepared two patches to turn the existing doctests into "normal" tests:
>>>
>>>http://projects.scipy.org/scipy/numpy/ticket/87
>>>http://projects.scipy.org/scipy/numpy/ticket/88
>>>
>>>
>>>
>>>      
>>>
>>In general, I'm not a big fan of turning doctests into "normal" tests.
>>Any time you muck with a working test you have to worry about
>>introducing bugs into the test suite. In addition doctests are
>>frequently, although certainly not always. clearer than their unit test
>>counterparts. It seems that the time would be better spent fixing trace
>>to do the right thing in the presence of doctests. Then again, you've
>>already spent the time so it's to late to unspend it I suppose.
>>    
>>
>
>I agree with you -- rewriting tests is suboptimal. However, in the presence
>of not-perfect-yet tools I prefer to adapt my way of working so that I can
>still use the tool instead of hoping that the tool will get fixed at some
>undefined time in the future.
>  
>
I just googled and there seem to be some patches relating to trace.py 
and doctest, but not being a user of trace, I don't really know what its 
issues are with doctest, so I'm unsure if they would address the issue 
you are having.


>Anyway, as I noted in ticket #87, the last doctest in test_ufunclike might
>be hiding a bug or there might be floating point math issues I'm unaware of.
>When I run my "normal" tests for log2, I get:
>
>Traceback (most recent call last):
>  File "numpybug3.py", line 7, in ?
>    assert_array_equal(b, array([2.169925, 1.20163386, 2.70043972]))
>  File "C:\Python24\Lib\site-packages\numpy\testing\utils.py", line 204, in
>assert_array_equal
>    assert cond,\
>AssertionError:
>Arrays are not equal (mismatch 100.0%):
>        Array 1: [ 2.1699250014423126  1.2016338611696504
>2.7004397181410922]
>        Array 2: [ 2.1699250000000001  1.2016338600000001
>2.7004397199999999]
>
>Is this the expected behaviour?
>  
>
I think that this is a non bug, it's just that the regular test is more 
picky here. Take a look at this:

 >>> a = n.array([ 2.1699250014423126,  
1.2016338611696504,2.7004397181410922])
 >>> a
array([ 2.169925  ,  1.20163386,  2.70043972])
 >>> b = n.array([ 2.169925  ,  1.20163386,  2.70043972])
 >>> b
array([ 2.169925  ,  1.20163386,  2.70043972])
 >>> a == b
array([False, False, False], dtype=bool)
 >>> [x for x in a]
[2.1699250014423126, 1.2016338611696504, 2.7004397181410922]
 >>> [x for x in b]
[2.1699250000000001, 1.2016338600000001, 2.7004397199999999]


So what we have here is that numpy displays less digits whan it actually 
knows.  Presumably this doctest was pasted in from the interpreter where 
not all the digits show up, then when you moved this to unittest where 
you are comparing the actual numbers, things start to fail.

Regards,

-tim






More information about the NumPy-Discussion mailing list