[Numpy-discussion] Some comments on the Numeric3 Draft of 1-Mar-05

konrad.hinsen at laposte.net konrad.hinsen at laposte.net
Wed Mar 2 00:03:16 EST 2005

On 01.03.2005, at 20:08, Colin J. Williams wrote:

> Basic Types
>  These are, presumably,  intended as the types of the data elements 
> contained in an Array instance.  I would see then as sub-types of 
> Array.

Element types as subtypes???

>  I wonder why there is a need for 30 new types.  Python itself has 
> about 30 distinct types.  Wouldn't it be more saleable to think in 
> terms of an Array

The Python standard library has hundreds of types, considering that the 
difference between C types and classes is an implementation detail.

>  Suppose one has:
>  import numarray.numerictypes as _nt
>  Then, the editor (PythonWin for example) responds to the entry of 
> "_nt." with a drop down menu offering the available types from which 
> the user can select one.

That sounds interesting, but it looks like this would require specific 
support from the editor.

>  I suggest that Numeric3 offers the opportunity to drop the word rank 
> from its lexicon.  "rank" has an established usage long before digital 
> computers.  See: http://mathworld.wolfram.com/Rank.html

The meaning of "tensor rank" comes very close and was probably the 
inspiration for the use of this terminology in array system.

>  Perhaps some abbreviation for "Dimensions" would be acceptable.

The equivalent of "rank" is "number of dimensions", which is a bit long 
for my taste.

>  len() seems to be treated as a synonym for the number of dimensions.  
> Currently, in numarray, it follows the usual sequence of sequences 
> approach of Python and returns the number of rows in a two dimensional 
> array.

As it should. The rank is given by len(array.shape), which is pretty 
much a standard idiom in Numeric code. But I don't see any place in the 
PEP that proposes something different!

> Rank-0 arrays and Python Scalars
>  Regarding Rank-0 Question 2.  I've already, in effect, answered 
> "yes".  I'm sure that a more compelling "Pro" could be written

Three "pro" argument to be added are:

- No risk of user confusion by having two types that are nearly but not
   exactly the same and whose separate existence can only be explained
   by the history of Python and NumPy development.

- No problems with code that does explicit typechecks (isinstance(x, 
   or type(x) == types.FloatType). Although explicit typechecks are 
   bad practice in general, there are a couple of valid reasons to use 

- No creation of a dependency on Numeric in pickle files (though this 
   also be done by a special case in the pickling code for arrays)

>  The "Con" case is valid but, I suggest, of no great consequence.  In 
> my view, the important considerations are (a) the complexity of 
> training the newcomer and (b) whether the added work should be imposed 
> on the generic code writer or the end user.  I suggest that the aim 
> should be to make things as easy as possible for the end user.

That is indeed a valid argument.

> Mapping Iterator
>  An example could help here.  I am puzzled by "slicing syntax does not 
> work in constructors.".

Python allows the colon syntax only inside square brackets. x[a:b] and 
x[a:b:c] are fine but it is not possible to write iterator(a:b).  One 
could use iterator[a:b] instead, but this is a bit confusing, as it is 
not the iterator that is being sliced.


More information about the NumPy-Discussion mailing list