larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Mon, Feb 8, 2010 at 8:42 PM,  <josef.pktd@xxxxxxxxx> wrote:
> On Mon, Feb 8, 2010 at 11:16 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>> On Mon, Feb 8, 2010 at 7:54 PM,  <josef.pktd@xxxxxxxxx> wrote:
>>> (back on mailinglist)
>>>
>>> On Mon, Feb 8, 2010 at 10:26 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>> On Mon, Feb 8, 2010 at 4:02 PM,  <josef.pktd@xxxxxxxxx> wrote:
>>>>> I don't have a strong opinion either about the dimension reduction,
>>>>> for consistency with the numpy philosophy the dimension should be
>>>>> reduced, for working with larry it is easier for a user to remove than
>>>>> to add an axis.
>>>>
>>>> How about insertaxis for the name? Or do you like addaxis better?
>>>>
>>>> insertaxis(axis=0, label=None)
>>>>
>>>
>>> definitely not expand_dims, I had to look at the changes in scipy svn to find it
>>>
>>> I usually think of it as addaxis, but I can get used to insertaxis
>>> (from list analogy)
>>>
>>> you can use np.expand_dims to insert axis into x
>>
>> Very nice. I didn't know that function existed. (It even handles
>> negative axes. I should make a unit test to make sure larry methods
>> can handle negative axes.)
>>
>
> I'm just reading the new lix
>
> For this case  lar.lix[['a']:['b']:2]
>
> why do you need the list check? you raise a ValueError if it's not a
> list. this and the fact that slicing start and stop need to be valid
> labels, seems to indicate that the list is not necessary, i.e.
> lar.lix['a':'b':2] , and lar.lix['a':'b':2,...]  should be unambiguous
> for any label type.
> Do you have an example where this would break? I don't see one right now.

Yes, good point, removing the list requirement for slices should work.
If, however, we keep the list requirement, then by adding one if
statement to lix we can also index with integers:

lar.lix[0, ['a', 'b']]
lar.lix[1:[date1]]
lar.lix[5, [date1]:-1]

That might make it easier to loop:

for i in range(lar.shape[0]):
    date = datetime.date(2010,1,1) + datetime.timedelta(i)
    y = lar.lix[i, [date]]

And I could even eventually add some tuple support in the form:

lar.lix[([date] - 10):[date]]

Yes, I think  that woul be powerful. And the integer support comes for
free if we keep the list requirement.

What do you think?

> I think you can merge if your unit tests pass. Some cosmetic cleaning
> we could also do in the main branch, e.g. maybe the code duplication
> is not necessary (unless it's not really duplicate, I'm only reading)
>
> Are you ok with merging? There might be a merge conflict with the
> changelog. I got one each time, I merge your branch.
>
> Josef
>