[Numpy-discussion] MapIter api

[Sebastian Berg]

On Mon, 2013-04-15 at 13:36 -0600, Charles R Harris wrote:
> 
> 
> On Mon, Apr 15, 2013 at 1:27 PM, Sebastian Berg
> <sebastian at sipsolutions.net> wrote:
>         On Mon, 2013-04-15 at 11:16 -0600, Charles R Harris wrote:
>         >
>         >
>         > On Mon, Apr 15, 2013 at 10:29 AM, Sebastian Berg
>         > <sebastian at sipsolutions.net> wrote:
>         >         Hey,
>         >
>         >         the MapIter API has only been made public in master
>         right?

<snip>

>         > Looks like the public API went in last August but didn't
>         make it into
>         > the 1.7.x release. What sort of schedule are you looking at?
>         >
>         
>         Not sure about a schedule, I somewhat think it is not even
>         that hard,
>         but of course it would still take a while (once I get a bit
>         further, I
>         will put it out there, hopefully someone else will be
>         interested to
>         help), but certainly not aiming to get anything done for 1.8.
>         
>         My first idea was to just do the parsing differently and keep
>         the
>         mapiter part identical (or with minor modifications). That
>         seems
>         actually impractical, since MapIter has a lot of stuff that it
>         does not
>         need. Plus it seems to me that it might be worth it to use the
>         new
>         nditer. One could try keep the fields somewhat identical
>         (likely
>         identical enough to be binary compatible with that ufunc.at
>         pull request
>         even), but I am not even sure that that is something to aim
>         for, since
>         the ufunc.at could be modified too (and might get good speed
>         improvements out of that).
>         
>         - Sebastian
>         
> 
> Makes me wonder if we should expose the API in 1.8 if you are thinking
> a change might be appropriate. Or am I missing something here?
> 
Yeah, I am wondering about that. But since I am not clear on exactly if
and how one would reimplement it right now (certainly it would look very
similar in the basic design), there is a bit time before deciding that
maybe. And maybe someone else has an opinion one way or another? 

For example the MapIter currently does not expose the subspace as a
separate iterator. You could access it, but you cannot optimize subspace
iteration by handling it separately. I am thinking about something like
the np.nestediters, but the user would maybe have to check if the inner
iterator even exists (the subspace can easily be 0-d or have only one
element).
Also, I could imagine to tag a second array onto the fancy index
iteration itself. That would be iterated together with the fancy indexes
in one nditer and return pointers into its own subspace. That array
would be the value array in assignment or the new array in subscription.

- Sebastian

> Chuck 
> 
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion