I have a need to index my array(s) starting with a 1 instead of a 0. The reason for this is to be consistent with the documentation of a format I'm accessing. I know I can just '1' from what the documentation says, but that can get cumbersome. Is there a magic flag I can pass to a numpy array (maybe when it is created) so I can index starting at 1 instead of the Python default? Thanks, Jeremy
Hi Jeremy
On Thu, Jul 28, 2011 at 3:19 PM, Jeremy Conlin
I have a need to index my array(s) starting with a 1 instead of a 0. The reason for this is to be consistent with the documentation of a format I'm accessing. I know I can just '1' from what the documentation says, but that can get cumbersome.
Is there a magic flag I can pass to a numpy array (maybe when it is created) so I can index starting at 1 instead of the Python default?
You may want to have a look at some of the labeled array packages out there, such as larry, datarray, pandas, etc. I'm sure at least one of them allows integer relabelling, although I'm not certain whether it can be done in a programmatic fashion. An alternative may be to create an indexing function that remaps the input space, e.g.: def ix(n): return n  1 x[ix(3), ix(5)] But that looks pretty nasty, and you'll have to expand ix quite a bit to handle slices, etc. :/ Stéfan
Don't forget the everythinglookslikeanail approach: make all your
arrays one bigger than you need and ignore element zero.
Anne
On 7/28/11, Stéfan van der Walt
Hi Jeremy
On Thu, Jul 28, 2011 at 3:19 PM, Jeremy Conlin
wrote: I have a need to index my array(s) starting with a 1 instead of a 0. The reason for this is to be consistent with the documentation of a format I'm accessing. I know I can just '1' from what the documentation says, but that can get cumbersome.
Is there a magic flag I can pass to a numpy array (maybe when it is created) so I can index starting at 1 instead of the Python default?
You may want to have a look at some of the labeled array packages out there, such as larry, datarray, pandas, etc. I'm sure at least one of them allows integer relabelling, although I'm not certain whether it can be done in a programmatic fashion.
An alternative may be to create an indexing function that remaps the input space, e.g.:
def ix(n): return n  1
x[ix(3), ix(5)]
But that looks pretty nasty, and you'll have to expand ix quite a bit to handle slices, etc. :/
Stéfan _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
 Sent from my mobile device
On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald
Don't forget the everythinglookslikeanail approach: make all your arrays one bigger than you need and ignore element zero.
Hehe, why didn't I think of that :) I guess the kind of problem I struggle with more frequently is books written with summations over m to +n. In those cases, it's often convenient to use the mapping function, so that I can enter the formulas as they occur. Stéfan
On 29.07.2011, at 1:19AM, Stéfan van der Walt wrote:
On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald
wrote: Don't forget the everythinglookslikeanail approach: make all your arrays one bigger than you need and ignore element zero.
Hehe, why didn't I think of that :)
I guess the kind of problem I struggle with more frequently is books written with summations over m to +n. In those cases, it's often convenient to use the mapping function, so that I can enter the formulas as they occur.
I don't want to open any cans of worms at this point, but given that Fortran90 supports such indexing (arbitrary limits, including negative ones), there definitely are use cases for it (or rather, instances where it is very convenient at least, like in Stéfan's books). So I am wondering how much it would take to implement such an enhancement for the standard ndarray... Cheers, Derek
On Thu, Jul 28, 2011 at 4:26 PM, Derek Homeier
I guess the kind of problem I struggle with more frequently is books written with summations over m to +n. In those cases, it's often convenient to use the mapping function, so that I can enter the formulas as they occur.
I don't want to open any cans of worms at this point, but given that Fortran90 supports such indexing (arbitrary limits, including negative ones), there definitely are use cases for it (or rather, instances where it is very convenient at least, like in Stéfan's books). So I am wondering how much it would take to implement such an enhancement for the standard ndarray...
Thinking about it, expanding on Anne's solution and the fact that Python allows negative indexing, you can simply reshuffle the array after operations a bit and have everything work out. import numpy as np n = 5 m = 7 x = np.zeros((m  n), dtype=float) # Do some operation with n..m based indexing for i in range(5, 7): x[i] = i # Construct the output x = np.hstack((x[n:], x[:m])) print x Regards Stéfan
The can is open and the worms are everywhere, so:
The big problem with onebased indexing for numpy is interpretation.
In python indexing, 1 is the last element of the array, and ranges
have a specific meaning. In a hypothetical onebased indexing scheme,
would the last element be element 0? if not, what does looking up zero
do? What about ranges  do ranges still include the first endpoint and
not the second? I suppose one could choose the most pythonic of the
1based conventions, but do any of them provide fromtheend indexing
without special syntax?
Once one had decided what to do, implementation would be pretty easy 
just make a subclass of ndarray that replaces the indexing function.
Anne
On 28 July 2011 19:26, Derek Homeier
On 29.07.2011, at 1:19AM, Stéfan van der Walt wrote:
On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald
wrote: Don't forget the everythinglookslikeanail approach: make all your arrays one bigger than you need and ignore element zero.
Hehe, why didn't I think of that :)
I guess the kind of problem I struggle with more frequently is books written with summations over m to +n. In those cases, it's often convenient to use the mapping function, so that I can enter the formulas as they occur.
I don't want to open any cans of worms at this point, but given that Fortran90 supports such indexing (arbitrary limits, including negative ones), there definitely are use cases for it (or rather, instances where it is very convenient at least, like in Stéfan's books). So I am wondering how much it would take to implement such an enhancement for the standard ndarray...
Cheers, Derek
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 29.07.2011, at 1:38AM, Anne Archibald wrote:
The can is open and the worms are everywhere, so:
The big problem with onebased indexing for numpy is interpretation. In python indexing, 1 is the last element of the array, and ranges have a specific meaning. In a hypothetical onebased indexing scheme, would the last element be element 0? if not, what does looking up zero do? What about ranges  do ranges still include the first endpoint and not the second? I suppose one could choose the most pythonic of the 1based conventions, but do any of them provide fromtheend indexing without special syntax?
I forgot, this definitely needs to be preserved for ndarray!
Once one had decided what to do, implementation would be pretty easy  just make a subclass of ndarray that replaces the indexing function.
In fact, Stéfan's reshuffling trick does nearly everything I would expect for using negative indices, maybe the only functionality needed to implement is 1. define an attribute like x.start that could tell appropriate functions (e.g. for print(x) or plot(x)) the "zeropoint", so x would be evaluated e.g. at x[5], wrapping around at [x1], x[0] to x[6]... Should have the advantage that anything that's not yet aware of this attribute could simply ignore it. 2. allow to automatically set this starting point when creating something like "x = np.zeros(5:7)" or setting a shape to (5:7)  but maybe the latter is leading into very dangerous territory already... Cheers, Derek
participants (4)

Anne Archibald

Derek Homeier

Jeremy Conlin

Stéfan van der Walt