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

Joshua Holbrook josh.holbrook at gmail.com
Thu Jul 8 16:59:54 EDT 2010


On Thu, Jul 8, 2010 at 12:20 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jul 8, 2010 at 1:15 PM, Lluís <xscript at gmx.net> wrote:
>>
>>
>>> My impression from SciPy was that people would prefer separate
>>> accessors for names and indices, especially because integers (a really
>>> common data type, after all) shouldn't be forbidden. Also, working
>>> with strings of integers like '2010' makes me feel like I'm using PHP,
>>> a feeling I like to avoid whenever possible. :)
>>
>> This boils down to one single question: must it be allowed to index with a mix
>> of names (whatever their type) _and_ "good-old" integer indexes that are not
>> "translated"?
>
> 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.
>
>
> Cheers,
>
> f
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>


> arr[int] -> normal indexing
> arr.somethin[int] -> tick-based indexing, where an int can mean anything.

^^This looks nice to me.

--Josh



More information about the NumPy-Discussion mailing list