[SciPy-dev] Re: Fundamental scipy testing changes

[Pearu Peterson]

On Tue, 7 Dec 2004, Todd Miller wrote:

>> Note that assert_equal, assert_almost_equal, assert_approx_equal
>> were not meant to be used with array arguments (I didn't implement them
>> but its obvious from reading the code).
>
> Thanks for pointing this out...  I noticed the array versions only
> peripherally and didn't understand the distinction.

May be we need to review assert_equal, etc so that they will
handle array inputs similar to assert_array_equal but on Python objects
they will not use unnecessary scipy_base.all. And then define

assert_array_equal = assert_equal
assert_array_almost_equal = assert_almost_equal

in testing.py for backward compability and declare their use as 
depreciated.

>> For checking the equality of
>> array arguments assert_array_equal or assert_array_almost_equal should be
>> used. If some scipy test suite uses assert_equal, etc with array
>> arguments then I think this is a bug of this particular test suite,
>> not of testing.py. So, using scipy_base.all in assert_equal, etc is not
>> necessary (unless we want to drop assert_array_* functions).
>
> Understood.  Are we agreed that it is appropriate to use all() in the
> assert_array_* functions?

Yes.

But be careful when replacing `if obj:` with `if all(obj):` in other parts
of scipy as it may also mean `if any(obj):` or `if obj is not None:`, in 
fact, I think these are being assumed in most cases. And if not, then 
it should be a bug.

I agree that the usage of `if obj:` is a bug and should be fixed either to
`if any(obj):` or `if obj is not None:` or rarely `if all(obj):`.

Pearu