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
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.
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
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.
Zach _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http:// projects.scipy.org/mailman/listinfo/scipy-dev
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/
On Thu, Aug 14, 2008 at 4:22 PM, Jarrod Millman <millman@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@gmail.com http://graphics.cs.uiuc.edu/~wnbell/
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
On Thu, Aug 14, 2008 at 4:12 PM, Zachary Pincus <zachary.pincus@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
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
On Fri, Aug 15, 2008 at 10:26 AM, Zachary Pincus <zachary.pincus@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.
participants (7)
-
Alan McIntyre -
Charles Doutriaux -
Charles R Harris -
Jarrod Millman -
Nathan Bell -
Yosef Meller -
Zachary Pincus