With numpy 1.6.2, it is working. So this is an interface change. Are you sure you want this? This break existing code.
I do not understand what you mean by slot? I'm not sure is the PyArray_SWAP is a good long term idea. I would not make it if it is only for temporarily. To set the base ptr, there is PyArray_SetBaseObject() fct that is new in 1.7. Is a similar fct useful in the long term for numpy? In the case where we implement differently the ndarray object, I think it won't be useful. We will also need to know how the memory is laid out by numpy for performance critical code. We we will need an attribute that tell the intern structure used. So do you want to force this interface change in numpy 1.7 so that I need to write codes now or can I wait to do it when you force the new interface? Currently the used code for PyArray_BYTES is: #define PyArray_BYTES(obj) ((char *)(((PyArrayObject_fields *)(obj))->data)) if I change it to #define PyArray_BYTES(obj) ((((PyArrayObject_fields *)(obj))->data)) it work! I don't understand why removing the case make it work. the data field is already an (char*), so this should not make a difference to my underderstanding. But I'm missing something here, do someone know? Fred On Tue, Oct 2, 2012 at 1:47 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Tue, Oct 2, 2012 at 11:43 AM, Charles R Harris > <charlesr.har...@gmail.com> wrote: >> >> >> >> On Tue, Oct 2, 2012 at 11:30 AM, Frédéric Bastien <no...@nouiz.org> wrote: >>> >>> On Tue, Oct 2, 2012 at 1:18 PM, Charles R Harris >>> <charlesr.har...@gmail.com> wrote: >>> > >>> > >>> > On Tue, Oct 2, 2012 at 9:45 AM, Frédéric Bastien <no...@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 > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
