[Numpy-discussion] one-offset arrays
nodwell at physics.ubc.ca
Thu Aug 30 04:07:48 EDT 2001
Thanks to everyone who responded to my comments about one-offset
arrays in Python. I understand much better now why zero-offset arrays
are a good choice for Python. For the reasons already discussed
(mostly ease of translating one-offset algorithms), one-offset arrays
would nevertheless be useful in certain situations, so I went ahead
and wrote a class for a one-offset array.
It ended up being a somewhat bigger job than I expected, and since it
is rather too much material for a mailing-list submission I created a
web site for it. Anyone who is interested in this topic please have a
I'd love some feedback along the following lines:
1. There are 4 outstanding problems/bugs which I could identify but
was unable to fix. Most of these seem to be due to limitations of the
UserArray class, but they could also be due to limitations of the
programmer. None of these problems make the class unusable. One of
them is the issue which Travis identified about functions taking
UserArrays but returning standard arrays. It would be nice if the
resulting discussion led to something be done... Any suggestions for
fixing the other 3 issues would be most welcome.
2. I would like this module to be as accessible as possible to others,
particularly those who are just getting started with Python and may
therefore be especially encumbered with one-offset baggage. How can I
do this? Submit it to a Python resource such as the Vaults of
Parnassus? Get people to link to my web page? Does someone with a more
prominant website want to volunteer to host it? Is there any
possibility of having it included eventually with Numerical Python or
Scientific Python? Probably some people will consider it too trivial
to include, but I found it less trivial than I expected once all the
cases were covered - and there are still the 4 outstanding
issues. (Yes the code sucks! Suggestions for improvement are most
welcome!) Why make people reinvent the wheel? People coming from
MatLab for example might be inclined to give up and go back to MatLab.
P.S. In case anyone is interested in the outstanding problems but for
some reason doesn't want to or can't visit the web site, here are the
for loops don't work with variables of type arrayone
for item in X:
This just generates an error.
In Python, a for loop works by starting at x(0) and incrementing until
an out-of-bounds error occurs. arrayone types have no 0 element.
Cast to type array in for loops. For example
for item in array(X):
Is it possible to "overload" "for" so that it behaves differently for
Slicing an arrayone from 0 doesn't generate an error but it should.
This returns ArrayOne.arrayone([1, 2, 3]) instead of an error.
X[:3] results in a call to __getslice__ with low=0. This cannot be
distinguished from X[0:3]. Therefore in order to deal correctly with
the X[:] case, we have to assume that low=0 means an unspecified low.
If you don't trust your code, you have to implement specific checking
for this condition before slicing.
If it was possible to get access to the unparsed input (literally
'0:3' for example), this could be fixed.
Negative subscripts return a slice offset by -1 from the expected
This returns ArrayOne.arrayone([1, 2]) instead of
X[-3:-2] in the above example results in a call to __getslice__ with
low=1, high=2, which cannot be distinguished from X[1:2].
Don't use negative index slicing with arrayone types.
If had access to unparsed input, could fix this.
Functions which take arrayone arguments return type array.
Have to cast back into arrayone, for example:
More information about the NumPy-Discussion