[Numpy-discussion] np 1.7b2 PyArray_BYTES(obj)=ptr fail

Charles R Harris charlesr.harris@gmail....
Tue Oct 2 13:21:19 CDT 2012


On Tue, Oct 2, 2012 at 11:47 AM, Charles R Harris <charlesr.harris@gmail.com
> wrote:

>
>
> 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.
>

And what I was thinking of for this was something like a PyArray_SWAP, that
simply swaps the contents of two array structures. However, that needs to
be analysed closely for nasty side effects beyond the surprise of an array
unexpectedly changing all of its characteristics underneath its pointer.
It's inherently dangerous but probably essential for some things.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20121002/c47d9007/attachment-0001.html 


More information about the NumPy-Discussion mailing list