[Numpy-discussion] New patch for new mgrid / ogrid functionality

[Robert Kern]

On Wed, Sep 24, 2008 at 02:57, David Kaplan <David.Kaplan at ird.fr> wrote:
> Hi,
>
> On Tue, 2008-09-23 at 20:54 -0500, numpy-discussion-request at scipy.org
> wrote:
>> On Tue, Sep 23, 2008 at 09:39:53AM +0200, David Kaplan wrote:
>> > I would note that there is nothing in the API breakage that prevents
>> > doing what Gael mentions.  The only change is that:
>>
>> > > > X = mgrid[0:4, 0:4, 0:4]
>>
>> > would be replaced with:
>>
>> > X = asarray( mgrid[ 0:4, 0:4, 0:4 ] )
>>
>> Doesn't this force a data copy?
>>
>
> I am not sure if this forces a copy (asarray shouldn't for arrays,
> unlike array, but I am not sure what it does for lists that can
> trivially become arrays),

It does because the individual arrays are usually in different parts
of memory. You can't just make a single array that is the
concatenation of them without copying their contents to a new
contiguous block of memory.

> but if it does, you are getting it one way or
> another - in the non-API-breakage patch I sent, the asarray is
> incorporated into the class method itself.

Okay, then we shouldn't implement it that way.

> For Robert, the use cases I was talking about included ogrid - ogrid
> with or without non-slice arguments always returns a list, mgrid with
> non-slices returns a list, but mgrid with all slices returns an array.
> I find this funky, but I guess I am going upwind.

I don't particularly want mgrid to return sometimes an array and
sometimes a list, either. I want that functionality under a different
name.

The sine qua non here is that mgrid[slice,slice,slice] needs to
continue to behave as it currently does. We're simply not going to
break code for this.

> I personally find adding another object that does stuff like mgrid and
> ogrid, but not exactly the same, hard to swallow.  mgrid and ogrid are
> already pretty mysterious, adding another is going to make things worse.
> I was initially trying to make things easier for the new user by
> providing one function that does all of what you want in a transparent
> way; this solution seems to be going in the opposite direction.  If you
> do end up adding one, I would call it ndgrid as this is what the matlab
> equivalent is called.
>
> The idea of making it a function eliminates the use of slices, which is
> where the real power of nd_grid comes in, so I would not go that route.
> If you want to go with a new object, I would add a "force_array" option
> to nd_grid that would be checked before executing the asarray code -
> this option would be true for mgrid, but false for ogrid and "ndgrid".

+1.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco