[Numpy-discussion] Response to PEP suggestions

[konrad.hinsen at laposte.net]

On Feb 17, 2005, at 19:52, Travis Oliphant wrote:

> I like Francesc's suggestion that .typecode return a code and .type 
> return a Python class.   What is the attitude and opinion regarding 
> the use of attributes or methods for this kind of thing?  It always 
> seems to me so arbitrary as to what is an attribute or what is a 
> method.

My view of pythonicity is that retrieving a value should be written as 
attribute access. Methods are more appropriate if there are arguments 
(no choice then anyway) or side effects. So I'd have .type as an 
attribute.

BTW, as the goal is inclusion into the Python core, why not

1) Use Python type objects for array creation and as the values of the 
.type
     attribute.
2) Implement scalar types for those array element types that currently
     have no Python scalar equivalent (e.g. UInt16).
3) Implement the same set of attributes of methods for scalar types and
    arrays.

Then the distinction between scalars and rank-0 arrays would become a 
minor implementation detail rather than a topic of heated debate. In 
different words, I propose that the PEP should include unification of 
scalars and arrays such that for all practical purposes scalars *are* 
rank-0 arrays.

> One thing has always bothered me though.  Why is a double complex type 
> Complex64? and a float complex type Complex32.  This seems to break 
> the idea that the number at the end specifies a bit width.   Why don't 
> we just call it Complex64 and Complex128?  Can we change this?

+1

> PowerPC it is Float128.   Wouldn't it just be easier to specify 
> LDouble or 'g' then special-case your code?

Definitely.

> Sometimes it is useful to select out of an array some elements based 
> on it's linear (flattened) index in the array.   MATLAB, for example, 
> will allow you to take a three-dimensional array and index it with a 
> single integer based on it's Fortran-order:  x(1,1,1),  x(2,1,1), ...

Could you give an example where this would be useful? To me this looks 
like a feature that MATLAB inherited from Fortran, which had it for 
efficiency reasons in a time when compilers were not so good at 
optimizing index expressions.

I don't lile the "special case" status of such a construct either. It 
could lead to unpleasant bugs that would be hard to find by those who 
are not aware of the special case. I'd say that special cases need 
special justifications - and I don't see one here.

> discontiguous arrays.   It could be made to work if X.flat returned 
> some kind of specially-marked array, which would then have to be 
> checked every time indexing occurred for any array.  Or, there maybe 
> someway to have X.flat return an

I much prefer that approach, assuming there is a real use for this 
feature.

> Capping indexes was proposed because of what numarray does.   I can 
> only think that the benefit would be that you don't have to check for 
> and raise an error in the middle of an indexing loop or pre-scan the 
> indexes.  But, I suppose this is unavoidalbe, anyway.  Currently 
> Numeric allows specifying indexes that are too high in slices. It just 
> chops them.  Python allows this too, for slices.  So, I guess I'm just 
> specifying Python behavior.  Of course indexing with an integer that 
> is too large or too small will raise errors:

I am all for imitating Python list behaviour in arrays, but we should 
also watch out for pitfalls. Array index expressions are in general 
much more complex than list index expressions, so the risk of 
introducing bugs is also much higher, which might well justify a 
somewhat incompatible approach.

> This may be a bit controversial as it is a bit of a change.  But, my 
> experience is that quite a bit of extra code is written to check 
> whether or not a calculation returns a Python-scalar (because these 
> don't have the same methods as arrays).  In

The only method I can think of is typecode(). But if more array 
functionality is migrated to arrays, this might become more serious.

> When Python needs a scalar it will generally ask the object if it can 
> turn itself into an int or a float.   A notable exception is indexing 
> in a list (where Python needs an integer and won't ask the object to 
> convert if it can).  But int(b) always returns a Python integer if the 
> array has only 1 element.

Still, this is a major point in practice. There was a Numeric release 
at some point in history that always returned rank-0 array objects (I 
don't remember if by design or by mistake), and it broke lots of my 
code because I was using array elements as indices.

Another compatibility issue is routines in C modules that insist on 
scalar arguments.

As I outlined above, I'd prefer a solution in which the distinction 
disappears from the Python programmer's point of view, even if scalars 
and rank-0 arrays remain distinct in the implementation (which is 
reasonable for performance reasons).

> I'd like to know what reasons people can think of for ever returning 
> Python scalars  unless explicitly asked for.

Other than the pragmatic ones, consistency: arrays are container 
structures that store elements of particular types. You should get out 
what you put in.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Laboratoire Léon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: hinsen at llb.saclay.cea.fr
---------------------------------------------------------------------