[Numpy-discussion] MapIter api

[Sebastian Berg]

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? So
>         it is no
>         problem at all to change at least the mapiter struct, right?
>         
>         I got annoyed at all those special cases that make things
>         difficult to
>         get an idea where to put i.e. to fix the boolean array-like
>         stuff. So
>         actually started rewriting it (and I already got one big
>         function that
>         does all index preparation -- ok it is untested but its
>         basically
>         there).
>         
>         I would guess it is not really a big problem even if it was
>         public for
>         longer, since you shouldn't do those direct struct access
>         probably? But
>         just checking.
>         
>         Since I got the test which mimics complex indexes in the
>         tests, I thinks
>         it should actually be feasible to do bigger refactoring there
>         without
>         having to worry too much about breaking things.
>         
> 
> 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


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