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

[Colin J. Williams]

konrad.hinsen at laposte.net wrote:

> 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???

Sub-types in the sense that, given an instance a of Array, a.elementType 
gives us the type of the data elements contained in a.

>
>>  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.
>
I was thinking of the objects in the types module.

>>  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.
>
Yes, it is built into Mark Hammond's PythonWin and is a valuable tool.  
Unfortunately, it is not available for Linux.  However, I believe that 
SciTE and boa-constructor are intended to have the "completion" 
facility.  These open source projects are available both with Linux and 
Windows.

>>  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.

Yes: The total number of contravariant 
<http://mathworld.wolfram.com/ContravariantTensor.html> and covariant 
<http://mathworld.wolfram.com/CovariantTensor.html> indices of a tensor 
<http://mathworld.wolfram.com/Tensor.html>. The rank of a tensor 
<http://mathworld.wolfram.com/Tensor.html> is independent of the number 
of dimensions <http://mathworld.wolfram.com/Dimension.html> of the space 
<http://mathworld.wolfram.com/Space.html>.

I was thinking in terms of linear independence, as with Matrix Rank: The 
rank of a matrix <http://mathworld.wolfram.com/Matrix.html> or a linear 
map <http://mathworld.wolfram.com/LinearMap.html> is the dimension 
<http://mathworld.wolfram.com/Dimension.html> of the range 
<http://mathworld.wolfram.com/Range.html> of the matrix 
<http://mathworld.wolfram.com/Matrix.html> or the linear map 
<http://mathworld.wolfram.com/LinearMap.html>, corresponding to the 
number of linearly independent 
<http://mathworld.wolfram.com/LinearlyIndependent.html> rows or columns 
of the matrix, or to the number of nonzero singular values 
<http://mathworld.wolfram.com/SingularValue.html> of the map.

I guess there has been a tussle between the tensor users and the matrix 
users for some time.

>
>>  Perhaps some abbreviation for "Dimensions" would be acceptable.
>
>
> The equivalent of "rank" is "number of dimensions", which is a bit 
> long for my taste.

Perhaps nDim, numDim or dim would be acceptable.

>
>>  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!

This was probably my misreading of len(T).

>
>> 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.

Thanks, history has a pull in favour of retaining the current approach.

>
> - No problems with code that does explicit typechecks (isinstance(x, 
> float)
>   or type(x) == types.FloatType). Although explicit typechecks are 
> considered
>   bad practice in general, there are a couple of valid reasons to use 
> them.
>
I would see this as supporting the conversion to a scalar.  For example:

     >>> type(type(x))
    <type 'type'>
     >>> isinstance(x, float)
    True
     >>> isinstance(x, types.FloatType)
    True
     >>>

> - No creation of a dependency on Numeric in pickle files (though this 
> could
>   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.

Thanks.  It would be nice if a:b or a:b:c could return a slice object.

>
> Konrad.
>
Colin W.