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?

Chuck