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