larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Mon, Feb 8, 2010 at 11:08 AM,  <josef.pktd@xxxxxxxxx> wrote:
> On Mon, Feb 8, 2010 at 1:49 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>> On Mon, Feb 8, 2010 at 10:17 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>> On Mon, Feb 8, 2010 at 10:13 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>>> On Mon, Feb 8, 2010 at 12:39 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>>> Is there a better design? Would it be better to always reorder on
>>>>> binary operations even if the labels are aligned?
>>>>
>>>> I didn't have any good ideas when I briefly looked at the problem. I
>>>> think my example was when I tried to do a diff() (when I didn't know
>>>> much about larry yet), but I don't remember any details.
>>>>
>>>> For the time axis, ordering is important also for the moving functions
>>>> and eg. fill_forward.
>>>> For labels that are names, it would be nice to be able to work with
>>>> arbitrary ordering.
>>>>
>>>> Does _align sort every axis, even if only one axis has disagreement ?
>>>
>>> No. Only the axes that are not aligned:
>>>
>>>>> y1 = la.larry([[1,2],[3,4]], [[1,0],[0,1]])
>>>>> y2 = la.larry([[1,2],[3,4]], [[1,0],[1,0]])
>>>>> y1 + y2
>>>
>>> label_0
>>>    1
>>>    0
>>> label_1
>>>    0
>>>    1
>>> x
>>> array([[3, 3],
>>>       [7, 7]])
>>
>> I already ran into a problem with this design:
>>
>>        lar.lix['a'] # row 'a'
>>        lar.lix['a':] # row 'a' and everything to the right (slicing)
>>        lar.lix[:, 'a'] # column 'a'
>>        lar.lix['a', 'b', 'c'] # single element from 3d larry
>>        lar.lix[['a', 'b', 'c']] # rows 'a', 'b', and 'c'
>>        lar.lix['a':'b'] # slice
>>        lar.lix['a':'b':2] # slice with step
>>
>> Consider the first example above but instead of 'a', let's make the
>> label ('a', 2). Inside getitem I won't know what that means. Because:
>>
>>>> class Index(object):
>>   ....:     def __init__(self):
>>   ....:         pass
>>   ....:     def __getitem__(self, index):
>>   ....:         print index
>>   ....:
>>   ....:
>>>> idx = Index()
>>>> idx[('a', 1)]
>> ('a', 1)
>>>> idx['a', 1]
>> ('a', 1)
>>
>> So to allow indexing by labels that are tuples, I'll need to change
>> the design to:
>>
>>        lar.lix[['a']] # row 'a'
>>        lar.lix[['a']:] # row 'a' and everything to the right (slicing)
>>        lar.lix[:, ['a']] # column 'a'
>>        lar.lix[['a'], ['b'], ['c']] # single element from 3d larry
>>        lar.lix[['a', 'b', 'c']] # rows 'a', 'b', and 'c'
>>        lar.lix[['a']:['b']] # slice
>>        lar.lix[['a']:['b']:2] # slice with step
>>
>> Not as pretty. I'm starting to wonder if I should push this new
>> feature to a later release.
>
> I'm still thinking a lot in terms of other matrix languages, matlab, gauss
>
>>>> idx[('a', 1),:,:]
> (('a', 1), slice(None, None, None), slice(None, None, None))
>>>> idx[('a', 1),...]
> (('a', 1), Ellipsis)
>
> it would be possible to disallow the numpy shortcut for dropping the
> remaining slices.

Interesting idea.

> Does using lists remove all ambiguities, between labels that are
> lists, and a list of labels

labels cannot be lists since lists are used to mark which axis each
label belongs to. If we want lists to be labels then init would have
to become

larry(np.ones((2,3)), label1, label2)

instead of the current

larry(np.ones((2,3)), [label1, label2])

where label1 and label2 are lists.

For example, these

y = larry([1,2,3], [['a', 'b', 'c']])
y = larry([[1,2],[3,4]], [['a', 'b'], ['c', 'd']])

would become

y = larry([1,2,3], ['a', 'b', 'c'])
y = larry([[1,2],[3,4]], ['a', 'b'], ['c', 'd'])

And

y = larry(x, label)

would become

y = larry(x, *label)

if ndim > 1.

>>>> idx[['a', 1]]
> ['a', 1]
>>>> idx[['a', 1],:]
> (['a', 1], slice(None, None, None))
>>>> idx[['a', 'b', 'c'],:]
> (['a', 'b', 'c'], slice(None, None, None))
>
> I would go for an unambigous, but restricted implementation for the
> most common usecase, not try to match everything numpy can do.
>
> Josef
>