larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Mon, Feb 8, 2010 at 9:09 AM,  <josef.pktd@xxxxxxxxx> wrote:
> On Mon, Feb 8, 2010 at 11:54 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>> On Mon, Feb 8, 2010 at 7:31 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>> On Mon, Feb 8, 2010 at 10:18 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>> On Mon, Feb 8, 2010 at 7:15 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>>>> On Mon, Feb 8, 2010 at 10:05 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>>>> After a long thread on how to support label indexing in larry, here's
>>>>>> where we ended up:
>>>>>>
>>>>>> 1. Remove the indexing of labels by strings from the trunk.
>>>>>>
>>>>>> 2. Create a method larry.lix that can be used for label indexing like this:
>>>>>>
>>>>>> lar.lix['a']
>>>>>> lar.lix['a':]
>>>>>> lar.lix[:, 'a']
>>>>>> lar.lix['a', 'b', 'c':]
>>>>>
>>>>> I'm not sure what the last index means, if there are several labels
>>>>> for the same axis, they would need to be in a list_like
>>>>> lar.lix[['a', 'b', 'c'], :]   to distinguish different elements for
>>>>> one axis from elements for several axis.
>>>>
>>>> Yep. Good catch. Typo.
>>>
>>> just for clarification, you also want to support label slices?
>>>
>>> lar.lix[['a', 'b', 'c'], '2009-01-01':]  or
>>> lar.lix[['a', 'b', 'c'], date1 :date2]
>>>
>>> I don't think there is any ambiguity in the interpretation
>>
>> Yes, slices will be supported. So both of your examples will work if
>> the corresponding labels exists. Looking at your date slice made be
>> realize that larry needs a sortlabel method
>>
>> def sortlabel(axis=None):
>>    etc.
>>
>> where axis=None will sort all axes.
>
> When I started initially to work with some examples I found the label
> ordering a bit confusing. I think any call to _align returns a larry
> with sorted labels. Initially I had a descending sorted larry and
> after some binary operations, I had a ascending sorted larry.
>
> There is currently no guarantee of preserving label ordering unless
> it's ascending sort order, is there?
> I'm not sure what the policy is, and I don't think that there are any
> unit tests that would check label ordering.

That's a good point. Something to add to the sphinx doc in the
alignment section.

There is no way to preserve label ordering in arbitrary binary
operations since the labels of the two inputs could be different. If
any alignment is needed larry sorts the labels. But If no alignment is
needed larry doesn't sort. So if my labels are in reverse order they
will remain reversed if added to an larry with the same labels in the
same order. But if you add a reversed label larry to a non-reserved,
then a non-reverse larry is returned.

Lable ordering should not be importants for larrys since alignment is
automatic. But that break when we do stuff like

idx = lar.labelindex(date)
lar[:,idx+1-100:idx+1]

Is there a better design? Would it be better to always reorder on
binary operations even if the labels are aligned?

>
> Josef
>
>>
>>>
>>>>>
>>>>> Josef
>>>>>
>>>>>>
>>>>>> Only labels and slices are allowed. Inside the function the labels
>>>>>> will be converted to indices and then a call will be made to
>>>>>> lar[converted_index].
>>>>>>
>>>>>> 3. Indexing with more than one list will do rectangular indexing, not
>>>>>> fancy indexing.
>>>>>>
>>>>>> OK, that's it. I'll start. I'll need help with #3
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~larry-discuss
>>>>>> Post to     : larry-discuss@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~larry-discuss
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>
>>>
>>
>