So the underlying problem with the controversial inplace_increment PR[1] is that currently, there's actually nothing in the public numpy API that exposes the workings of numpy indexing. The only thing you can do with a numpy index is call ndarray.__getattr__ or __setattr__. This is a pretty obvious gap, given how fundamental an operation indexing is in numpy (and how difficult to emulate). So how can we expose something that fixes it? Make PyArrayMapIterObject part of the public API? Something else? -n [1] https://github.com/numpy/numpy/pull/326
On Jul 19, 2012, at 3:50 AM, Nathaniel Smith wrote:
So the underlying problem with the controversial inplace_increment PR[1] is that currently, there's actually nothing in the public numpy API that exposes the workings of numpy indexing. The only thing you can do with a numpy index is call ndarray.__getattr__ or __setattr__. This is a pretty obvious gap, given how fundamental an operation indexing is in numpy (and how difficult to emulate). So how can we expose something that fixes it? Make PyArrayMapIterObject part of the public API? Something else?
I think you meant ndarray.__getitem__ and ndarray.__setitem__ As I mentioned in the comments, the original intention was to make PyArrayMapIterObject part of the public API. However, I was not able to make it work in the way I had intended back then. Exposing the MapIterObject is a good idea (but it would have to be exposed already bound to an array) --- i.e. you create a new API that binds to a particular array and then expose the PyArray_MapIterNext, etc. functions. Perhaps something like: PyArray_MapIterArray -Travis
On Thu, Jul 19, 2012 at 2:53 PM, Travis Oliphant
On Jul 19, 2012, at 3:50 AM, Nathaniel Smith wrote:
So the underlying problem with the controversial inplace_increment PR[1] is that currently, there's actually nothing in the public numpy API that exposes the workings of numpy indexing. The only thing you can do with a numpy index is call ndarray.__getattr__ or __setattr__. This is a pretty obvious gap, given how fundamental an operation indexing is in numpy (and how difficult to emulate). So how can we expose something that fixes it? Make PyArrayMapIterObject part of the public API? Something else?
I think you meant ndarray.__getitem__ and ndarray.__setitem__
As I mentioned in the comments, the original intention was to make PyArrayMapIterObject part of the public API. However, I was not able to make it work in the way I had intended back then.
Exposing the MapIterObject is a good idea (but it would have to be exposed already bound to an array) --- i.e. you create a new API that binds to a particular array and then expose the PyArray_MapIterNext, etc. functions.
Perhaps something like: PyArray_MapIterArray
There's now a PR for exposing this: https://github.com/numpy/numpy/pull/377 Since this is new API I hope people will take a look :-). The patch itself is pretty trivial, but it exposes an object that seems to have been only partially implemented, so we should also double-check that this isn't exposing any half-baked code. (mapping.c still says "Do not expose the MapIter_Type to Python", but I'm not really clear what the problems are. AFAICT it doesn't actually define *any* Python-accessible API, it's just an opaque object.) -n
participants (2)
-
Nathaniel Smith
-
Travis Oliphant