[Numpy-discussion] Some comments on the Numeric3 Draft of 1-Mar-05
Colin J. Williams
cjw at sympatico.ca
Wed Mar 2 09:22:16 CST 2005
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.
More information about the Numpy-discussion
mailing list