larry-discuss team mailing list archive

[josef.pktd@xxxxxxxxx]

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.

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