On Tue, Oct 2, 2012 at 1:44 PM, Frédéric Bastien <no...@nouiz.org> wrote:
> 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? > Pythonese for structure member ;) > > 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. > The C++ stdlib provides something similar for std::vector. One common use case would be to pass in a vector by reference that gets swapped with one on the stack. When the function exits the one on the stack is cleaned up and the vector that was passed in has the new data, but it has to be the same type. For PyArray_SWAP I was thinking of swapping everything: type, dims, strides, data, etc. That is what f2py does. > 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? > > Well, no we don't want to force you to use the new interface. If you don't define NPY_NO_DEPRECATED_API things should still work. Although if it is defined the function returns an rvalue, so some other method needs to be provided for what you are doing. > 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? > What I find strange is that it is the same macro in 1.7 and 1.6, only the name of the structure was changed. Hmm... This looks almost like some compiler subtlety, I wonder if the compiler version/optimization flags have changed? In any case, I think the second form would be more correct for the lvalue since the structure member is, as you say, already a char*. We want things to work for you as they should, so we need to understand this and fix it. <snip> Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
