headers
Zachary Pincus | 14 Aug 05:01
Favicon

PyArray_FromDims and friends

Hi all,

In testing out svn scipy and numpy, I noticed some run-time errors  
from scipy.interpolate because the _fitpack module's c sources use  
PyArray_FromDims and PyArray_FromDimsAndData, which are now deprecated  
in numpy svn.

I opened a ticket and made a patch for this particular case, but I'm  
not sure if there's an overall strategy (someone writes a very good  
regexp, say, and lets it loose), or if these will be fixed piecemeal.  
If the latter, here's the patch:

http://scipy.org/scipy/scipy/ticket/723

Zach
Permalink | Reply |
headers
Yosef Meller | 14 Aug 15:29

Re: PyArray_FromDims and friends

Zachary Pincus wrote:
> In testing out svn scipy and numpy, I noticed some run-time errors  
> from scipy.interpolate because the _fitpack module's c sources use  
> PyArray_FromDims and PyArray_FromDimsAndData, which are now deprecated  
> in numpy svn.

What is the preferred way to do it now? _minpack uses them everywhere too.
Permalink | Reply |
headers
Zachary Pincus | 14 Aug 16:55
Favicon

Re: PyArray_FromDims and friends

> Zachary Pincus wrote:
>> In testing out svn scipy and numpy, I noticed some run-time errors
>> from scipy.interpolate because the _fitpack module's c sources use
>> PyArray_FromDims and PyArray_FromDimsAndData, which are now  
>> deprecated
>> in numpy svn.
>
> What is the preferred way to do it now? _minpack uses them  
> everywhere too.

As far as I can tell, PyArray_FromDims can be replaced with  
PyArray_SimpleNew -- they have the same function signature. If you  
want to be correct/avoid compiler warnings, you'd probably need to  
make sure to cast the second argument to (npy_intp*).

Likewise, PyArray_FromDimsAndData can be replaced with  
PyArray_SimpleNewFromData, with the same caveat about the cast.

So: it's a simple regexp to fix these two if you don't care about the  
casting, and a slightly more-involved one if you do. I'm not sure  
what's best here.

Zach
Permalink | Reply |
headers
Charles Doutriaux | 14 Aug 18:28

Re: PyArray_FromDims and friends

You definately want to cast to npy_intp !
It did bite us when we went to 64bit!

C.

Zachary Pincus wrote:
>> Zachary Pincus wrote:
>>     
>>> In testing out svn scipy and numpy, I noticed some run-time errors
>>> from scipy.interpolate because the _fitpack module's c sources use
>>> PyArray_FromDims and PyArray_FromDimsAndData, which are now  
>>> deprecated
>>> in numpy svn.
>>>       
>> What is the preferred way to do it now? _minpack uses them  
>> everywhere too.
>>     
>
> As far as I can tell, PyArray_FromDims can be replaced with  
> PyArray_SimpleNew -- they have the same function signature. If you  
> want to be correct/avoid compiler warnings, you'd probably need to  
> make sure to cast the second argument to (npy_intp*).
>
> Likewise, PyArray_FromDimsAndData can be replaced with  
> PyArray_SimpleNewFromData, with the same caveat about the cast.
>
> So: it's a simple regexp to fix these two if you don't care about the  
> casting, and a slightly more-involved one if you do. I'm not sure  
> what's best here.
>
(Continue reading)

Permalink | Reply |
headers
Jarrod Millman | 14 Aug 22:22
Favicon

Re: PyArray_FromDims and friends

With the SciPy 0.7.0 release quickly approaching, I would really like
to get the rid of all the deprecated NumPy calls in SciPy.  While I
don't think they should hold up the beta releases, I would like them
all removed before the first release candidate.  All patches welcome.

There is no plan to systematically fix these, so please don't hesitate
to fix any area of the code that you feel comfortable working on.

Thanks,

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
Permalink | Reply |
headers
Nathan Bell | 14 Aug 22:45

Re: PyArray_FromDims and friends

On Thu, Aug 14, 2008 at 4:22 PM, Jarrod Millman <millman <at> berkeley.edu> wrote:
>
> There is no plan to systematically fix these, so please don't hesitate
> to fix any area of the code that you feel comfortable working on.
>

scipy.sparse should be fixed as of r4645

--

-- 
Nathan Bell wnbell <at> gmail.com
http://graphics.cs.uiuc.edu/~wnbell/
Permalink | Reply |
headers
Zachary Pincus | 15 Aug 00:12
Favicon

Re: PyArray_FromDims and friends

> With the SciPy 0.7.0 release quickly approaching, I would really like
> to get the rid of all the deprecated NumPy calls in SciPy.  While I
> don't think they should hold up the beta releases, I would like them
> all removed before the first release candidate.  All patches welcome.
>
> There is no plan to systematically fix these, so please don't hesitate
> to fix any area of the code that you feel comfortable working on.

OK, then the patch in:
http://scipy.org/scipy/scipy/ticket/723
should do it for scipy.interpolate. It includes the proper casting-to- 
(*npy_intp) for 64-bit platforms.

Zach
Permalink | Reply |
headers
Charles R Harris | 15 Aug 17:55

Re: PyArray_FromDims and friends



On Thu, Aug 14, 2008 at 4:12 PM, Zachary Pincus <zachary.pincus <at> yale.edu> wrote:
> With the SciPy 0.7.0 release quickly approaching, I would really like
> to get the rid of all the deprecated NumPy calls in SciPy.  While I
> don't think they should hold up the beta releases, I would like them
> all removed before the first release candidate.  All patches welcome.
>
> There is no plan to systematically fix these, so please don't hesitate
> to fix any area of the code that you feel comfortable working on.

OK, then the patch in:
http://scipy.org/scipy/scipy/ticket/723
should do it for scipy.interpolate. It includes the proper casting-to-
(*npy_intp) for 64-bit platforms.

No, no, you can't just cast the pointer to a different type, it needs to point to npy_intp instead of int to start with, i.e., n has to be an array of npy_intp.

Chuck 


_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply |
headers
Zachary Pincus | 15 Aug 19:26
Favicon

Re: PyArray_FromDims and friends

>
> OK, then the patch in:
> http://scipy.org/scipy/scipy/ticket/723
> should do it for scipy.interpolate. It includes the proper casting-to-
> (*npy_intp) for 64-bit platforms.
>
> No, no, you can't just cast the pointer to a different type, it  
> needs to point to npy_intp instead of int to start with, i.e., n has  
> to be an array of npy_intp.

Thanks for looking that over. This is of course what happens when I  
try to deal with C too late at night.

For cases where the dimension was 1, I had originally had:

[whatever] = (PyArrayObject  
*)PyArray_SimpleNew(1,&(npy_intp)n,PyArray_[whatever]);

But I got compiler warnings to the tune of "The argument to & is not  
strictly an lvalue. This will be a hard error in the future." Which  
makes sense, (npy_intp)n isn't a proper lvalue... So I changed it to:

[whatever] = (PyArrayObject *)PyArray_SimpleNew(1, 
(npy_intp*)&n,PyArray_[whatever]);

which, as you point out, is pretty daft.

Is there a correct, portable, and warning-free way to do this in one  
line? I'm guessing not. Anyhow, I'll fix the patch with a multi-line  
solution:
npy_int intp_n;
...
intp_n = (npy_intp) n;
[whatever] = (PyArrayObject  
*)PyArray_SimpleNew(1,&intp_n,PyArray_[whatever]);

Sorry for the noise, and thanks Chuck for the catch.

Zach
Permalink | Reply |
headers
Alan McIntyre | 6 Oct 10:54

Re: PyArray_FromDims and friends

On Fri, Aug 15, 2008 at 10:26 AM, Zachary Pincus
<zachary.pincus <at> yale.edu> wrote:
>> No, no, you can't just cast the pointer to a different type, it
>> needs to point to npy_intp instead of int to start with, i.e., n has
>> to be an array of npy_intp.
>
> Thanks for looking that over. This is of course what happens when I
> try to deal with C too late at night.
>
> For cases where the dimension was 1, I had originally had:
>
> [whatever] = (PyArrayObject
> *)PyArray_SimpleNew(1,&(npy_intp)n,PyArray_[whatever]);
>
> But I got compiler warnings to the tune of "The argument to & is not
> strictly an lvalue. This will be a hard error in the future." Which
> makes sense, (npy_intp)n isn't a proper lvalue... So I changed it to:
>
> [whatever] = (PyArrayObject *)PyArray_SimpleNew(1,
> (npy_intp*)&n,PyArray_[whatever]);
>
> which, as you point out, is pretty daft.
>
> Is there a correct, portable, and warning-free way to do this in one
> line? I'm guessing not. Anyhow, I'll fix the patch with a multi-line
> solution:
> npy_int intp_n;
> ...
> intp_n = (npy_intp) n;
> [whatever] = (PyArrayObject
> *)PyArray_SimpleNew(1,&intp_n,PyArray_[whatever]);
>
> Sorry for the noise, and thanks Chuck for the catch.

I added a patch to #723 (http://scipy.org/scipy/scipy/ticket/723) that
(I think) switches to use PyArray_SimpleNew instead of
PyArray_FromDims.  If nobody sees any problems with it I'll look it
over again tomorrow or Tuesday and apply it.  I'll try to get to
switching out PyArray_FromDimsAndDataAndDescr later this week if
nobody else gets around to it.
Permalink | Reply |

Gmane