[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