larry-discuss team mailing list archive

[josef.pktd@xxxxxxxxx]

On Sun, Feb 7, 2010 at 10:43 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
> On Sun, Feb 7, 2010 at 7:40 PM,  <josef.pktd@xxxxxxxxx> wrote:
>> On Sun, Feb 7, 2010 at 10:23 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>> On Sun, Feb 7, 2010 at 7:11 PM,  <josef.pktd@xxxxxxxxx> wrote:
>>>
>>>> If you want to go this way, you could have lixs :  lix with strings,
>>>> and lixr : lix with repr , ... ?
>>>> lix would be safe  because it uses the labels directly, the other ones
>>>> are only recommended in restricted cases where the string (or other)
>>>> representation makes sense.
>>>
>>> Too confusing with two I think.
>>>
>>>> if you want to allow slicing i.e. `:`  then I think lix would need to
>>>> use its __getitem__ instead of __call__ or __init__
>>>> lar1[1:4, lix['msft', google], lixs['2010-02-01':]   or lar1[1:4,
>>>> lix[['msft', google]], lixs['2010-02-01':] ?
>>>
>>> lar1[lix(date)]: will work. So will lar[lix(date1):lix(date2)]
>>>
>>> Allowing slices slows things down because now we have to look instead
>>> each slice object (slice.start, slice.stop) for lix object and if
>>> found convert them.
>>
>> I wouldn't mix lix and regular array slices or indices for the same
>> axis. I would restrict it to if either one of (slice.start,
>> slice.stop) are lix then both are interpreted as labels.
>>
>> either lar[lix[date1:date2],:]   or   lar[lix(date1):lix(date2), :]
>> but not lar[lix(date1):-3]
>
> How come? Seems handy to me.

Just a feeling, mixing oranges and apples, (If I have one label, I
expect also to have the other, or I have neither in the other case)

It would be useful to write a babyclass with the different versions of
getitem. It's easier to see what's going on and to experiment than
using the already more complicated getitem of larry.

Josef

>
>
>>
>>>
>>>> I don't know if lix should hold some code for conversion from label
>>>> representation to indices, or be just an identifier for use in
>>>> larry.__getitem__
>>>
>>> Yeah, a method getindex that takes label as input, perhaps. larry's
>>> getitem is already getting harry, so keeping the code in lix instead
>>> of adding yet more code to getitem might be a good idea. Or make a
>>> function in util.misc like a did for string indexing.
>>>
>>>> Josef
>>>>
>>>
>>
>