http://github.com/rspeer/datarray represents my best guess at the SciPy BOF consensus. I recently switched the method of accessing named ticks from .named() to .named[] based on further discussion here.
My implementation is still missing the case with named ticks but positional axes, however. That is, you should be able to use .named directly on the top-level datarray without referring to any axis labels, to say something like arr.named['Netherlands', 2010], but you can't yet. -- Rob On Thu, Jul 8, 2010 at 11:44 PM, Keith Goodman <[email protected]> wrote: > On Thu, Jul 8, 2010 at 1:20 PM, Fernando Perez <[email protected]> wrote: > >> The consensus at the BoF (not that it means it's set in stone, simply >> that there was good chance for back-and-forth on the topic with many >> voices) was that: >> >> 1. There are valid use cases for 'integer ticks', i.e. integers that >> index arbitrarily into an array instead of in 0..N-1 fashion. >> >> 2. That having plain arr[0] give anything but the first element in arr >> would be way too confusing in practice, and likely to cause too many >> problems. >> >> 3. That the best solution to allow integer ticks while retaining >> 'normal' indexing semantics for integers would be to have >> >> arr[int] -> normal indexing >> arr.somethin[int] -> tick-based indexing, where an int can mean anything. > > Has the Scipy 2010 BOF consensus been implemented in anyone's fork? I > don't understand the indexing so I'd like to try it. > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
