On Tue, Oct 2, 2012 at 11:43 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Oct 2, 2012 at 11:30 AM, Frédéric Bastien <nouiz@nouiz.org> wrote:
On Tue, Oct 2, 2012 at 1:18 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Oct 2, 2012 at 9:45 AM, Frédéric Bastien <nouiz@nouiz.org>
wrote:
We implement our own subtensor(x[...], where ... can be index or slice) c code due to the way Theano work.
I can probably change the logic, but if you plan to revert this interface changes, I prefer to wait for this change we someone else is doing other changes that would conflict. Also, I did a Theano release candidate and I really would like the final version to work with the next release of NumPy.
Well, you don't *have* to define NPY_NO_DEPRECATED_API. If you don't you can access the array as before using the macros even for future versions of numpy. The only way that could cause a problems is if the array structure is rearranged and I don't think that will happen anytime soon. On that account there has not been any discussion of reverting the changes. However, I'd like f2py generated modules to use the new functions at some point and in order to do that numpy needs to supply some extra functionality, I'm just not sure of the best way to do it at the moment. If I had a good idea of what you want to do it would help in deciding what numpy should provide.
I do not define NPY_NO_DEPRECATED_API, so I get g++ warning about that. That is the problem I have.
What I do is close to that:
alloc a new ndarray that point to the start of the ndarray I want to view with the right number of output dimensions.
Compute the new dimensions/strides and data ptr. Then set the data ptr to what I computed. Then set the base ptr.
I can reverse this and create the ndarray only at the end, but as this change break existing code here, it can break more code. That is why I wrote to the list.
doing "PyArray_BASE(xview) = ptr" work when I don't define NPY_NO_DEPRECATED_API, but do not work when I define NPY_NO_DEPRECATED_API. I would have expected the same for PyArray_BYTES/DATA.
Do this explain clearly the problem I saw?
Yes, thanks. I see in ndarraytypes.h
#define PyArray_DATA(obj) ((void *)(((PyArrayObject_fields *)(obj))->data))
I wonder if the cast to void* is causing a problem? Could you try char* instead?
Oops, the problem is that you need a pointer to the slot, not the pointer in the slot. That is, you need a different macro/function. Chuck