[Numpy-discussion] BOF notes: Fernando's proposal: NumPy ndarray with named axes

[Lluís]

Fernando Perez writes:
> 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.

Thanks for the summary. Then, does it make sense this scheme?

  arr[int] -> normal indexing
  arr[not int] -> IndexError
  arr.something[int] -> normal indexing (use str(int) for tick-based indexing)
  arr.something[not int] -> tick-based indexing

It's not that I'm trying to push for this scheme. In fact, my question is
whether this would be of any practical use. (e.g., arr.something['1900':-3], or
arr.named[0,'1900':])

If that is acceptable and performance wouldn't have a huge drop, then I'd rather
go for:

  arr[int] -> normal indexing
  arr[not int] -> tick-based indexing
                  I'm not sure if this was dropped because of the str(int) or
                  because of performance reasons
  arr.something[int] -> normal indexing
  arr.something[not int] -> tick-based indexing
  arr.named -> no longer necessary

Which has even less "keywords" to remember.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth