From: Colin J. W. <cj...@sy...> - 2005-03-02 17:21:59
|
kon...@la... 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. |