[Numpy-discussion] New patch for new mgrid / ogrid functionality
Wed Sep 24 03:13:06 CDT 2008
On Wed, Sep 24, 2008 at 02:57, David Kaplan <David.Kaplan@ird.fr> wrote:
> On Tue, 2008-09-23 at 20:54 -0500, firstname.lastname@example.org
>> 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
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".
"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
More information about the Numpy-discussion