FW: [Numpy-discussion] typecodes in numarray
perry at stsci.edu
Fri Jan 24 09:04:02 CST 2003
Todd Miller had some further comments that I thought were worth
posting as well (and I think he makes some very good points).
My [i.e. Todd's] thoughts about it:
>Maybe I'm becoming a bit tedious with this, but if you look at:
No. It shows you're thinking about it carefully. Having looked at all
of the examples below, I have some comments:
1. The sparseness and obscurity of the typecode "wordspace" are both
demonstrated here. There are so few letters to choose from, they're
often already used in some other context. Even given the large number
of unused letters, it's often difficult to choose good ones and to
remember what has been chosen. I think this is one of the reasons Perry
chose to replace typecodes with true type objects which have rich,
regular, and predictable symbolic names.
2. Typecodes were added as a backwards compatability feature of
numarray, and I think it's probable that numarray beat Numeric to
supporting most of these types, because otherwise they'd have been
copied directly and there would be no problem. I'm not really trying to
play a blame-game here, but I am making an argument that perhaps
numarray should only go so far in the support of what I regard as an
obsolescent feature. If the Numeric developers choose to continue
extending the use of typecodes in ways that are incompatible with
numarray, one way of dealing with it is to "just say no". We are going
beyond the scope of backwards compatability to on-going compatabilty.
(Which we may still have to do but needs to be discussed and considered)
3. STSCI has layered other software on top of numarray and recarray
which astronomers use to do work. It is the friction of that interface
which makes correcting these consistency problems more difficult than
might be immediately apparent.
>I think it's important to agree with a definitive set of charcodes and use
>them uniformly throughout numarray.
I wish this were possible, but I'm thinking we should try to find an
alternative approach altogether, one which may be more verbose but
implicitly free of conflict.
A means for specifying a recarray format might be created from tuples,
type objects, and integer repetition factors.
The verbosity of this approach might be a litte tedious, but it would
also be transparent, maintainable, and conflict free.
I think we should add an "obsolescent feature" warning to numarray and
recarray which flags any use of character typecodes when the appropriate
command line switches are set.
>Suggestion: if recarray charcodes are not necessary to match the Numeric
>ones, I propose that using the Python convention maybe a good idea.
>Look at the table in:
This sounds good to me, except that it will break an existing interface
that I don't have control over. Therefore, I suggest we correct the
problem by coming up with something better.
More information about the Numpy-discussion