FW: [Numpy-discussion] Bug: extremely misleading array behavior

[Konrad Hinsen]

"eric jones" <eric at enthought.com> writes:

> How about making indexing (not slicing) arrays *always* return a 0-D
> array with copy instead of "view" semantics?  This is nearly equivalent
> to creating a new scalar type, but without requiring major changes.  I
...

I think this was discussed as well a long time ago. For pure Python
code, this would be a very good solution. But 

> I think the only reason for the silent conversion is that Python lists
> only allow integer values for use in indexing so that:

There are some more cases where the type matters. If you call C
routines that do argument parsing via PyArg_ParseTuple and expect a
float argument, a rank-0 float array will raise a TypeError. All the
functions from the math module work like that, and of course many in
various extension modules.

In the ideal world, there would not be any distinction between scalars
and rank-0 arrays. But I don't think we'll get there soon.

> On coercion rules:
> 
> As for adding the array to a scalar value, 
> 
>   x = array([3., 4.], Float32)
>   y = x + 1.
> 
> Should y be a Float or a Float32?  I like numarray's coercion rules
> better (Float32).  I have run into this upcasting to many times to

Statistically they probably give the desired result in more cases. But
they are in contradiction to Python principles, and consistency counts
a lot on my value scale.

I propose an experiment: ask a few Python programmers who are not
using NumPy what type they would expect for the result. I bet that not
a single one would answer "Float32".

> On the other hand, I don't think a jump from 21 to 22 is enough of a
> jump to make such a change.  Numeric progresses pretty fast, and users

I don't think any increase in version number is enough for
incompatible changes. For many users, NumPy is just a building block,
they install it because some other package(s) require it. If a new
version breaks those other packages, they won't be happy. The authors
of those packages won't be happy either, as they will get the angry
letters.

As an author of such packages, I am speaking from experience. I have
even considered to make my own NumPy distribution under a different
name, just to be safe from changes in NumPy that break my code (in the
past it was mostly the installation code that was broken when
arrayobject.h changed its location).

In my opinion, anything that is not compatible with Numeric should not
be called Numeric.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------