[SciPy-dev] scipy.base passing tests

Travis Oliphant oliphant at ee.byu.edu
Wed Oct 5 00:02:53 CDT 2005


Robert Kern wrote:

>In my working copy, all of the tests for scipy.base pass. Except for the
>ones that don't. Before checking my stuff in, I want to get some
>feedback on these:
>
>* test_shape_base.test_apply_along_axis causes a segfault due to the
>put() on object arrays bug I posted about earlier. Personally, I've
>commented out this testcase so I could run the others.
>  
>
I'll look in to this one..

>* test_type_check.test_mintypecode has a few cases using savespace.
>That's obsolete now, but I'm not sure if there's new functionality we
>should test in its place.
>
>* Various tests in test_type_check want to divide scalar arrays by 0 to
>make nans and infs. This fails with a ZeroDivisionError. E.g.
>
>======================================================================
>ERROR: check_complex1 (scipy.base.type_check.test_type_check.test_isfinite)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File
>"/Users/kern/svk-projects/scipy_core/scipy/base/tests/test_type_check.py",
>line 162, in check_complex1
>    assert_all(isfinite(array(1+1j)/0.) == 0)
>ZeroDivisionError: complex division
>
>I'm not sure whether this is desired behavior, or the scalar array types
>should be modified to treat division by 0 like other arrays.
>
>  
>
No, I don't think it's desired.   

I think the right solution is to check in code for as_number methods of 
the array scalars that is specific to the different types of arrays 
(integers, float, complex, string, unicode, etc...).  Right now, they 
all inherit from the same gentype_as_number methods, which does 
different things depending on what is passed in.  Right now, if a mixed 
array  / normal Python object operation is done, I think the normal 
Python object  gets to try it's hand. 


Thus, the division by zero error.  Now, we could try to fix the generic 
code to be exactly what we want.  But, this seems unwieldy.  We already 
have different as_number tables we could play with (all the array 
scalars don't need to point to one function table which they do now).  
We have the opportunity to adjust the as_number tables to behave as we 
want,  so we really should just do that.     This will also speed up 
array scalar operations, because right now, they all go through 0 
dimensional arrays for their math which is slower.


-Travis




More information about the Scipy-dev mailing list