Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Tue, Nov 10, 2009 at 02:43, Fernando Perez wrote: > On Sun, Nov 8, 2009 at 11:43 PM, David Cournapeau > wrote: >> Fernando Perez wrote: >>> On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: >>> You find a C function pointer wrapped in a CObject in the ._cpointer attribute. >>> >>> Sorry, in the ._cpointer attribute of what precisely? >> >> If Sturla refers to CObject as defined in the python C API, then the >> underlying lapack functions are not wrapped into a C object (this is not >> done automatically). The lapack_lite functions such as dgeev and co are >> standard python function (with *self and *args args, i.e. wrappers >> around the underlying 'true' lapack function). > > Thanks, David. My question was because Sturla's language seemed to > suggest (at least it did to me) that there was some python object foo > where foo._cpointer would be a poniter to the raw C function one could > then manipulate with ctypes. Perhaps I just misunderstood, but thanks > for clarifying that at least this isn't possible today from pure > python. Only f2py functions have the ._cpointer attribute. In [3]: from scipy import linalg In [4]: linalg.flapack.dgeev._cpointer Out[4]: -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Sun, Nov 8, 2009 at 11:43 PM, David Cournapeau wrote: > Fernando Perez wrote: >> On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: >> >>> You find a C function pointer wrapped in a CObject in the ._cpointer >>> attribute. >>> >> >> Sorry, in the ._cpointer attribute of what precisely? > > If Sturla refers to CObject as defined in the python C API, then the > underlying lapack functions are not wrapped into a C object (this is not > done automatically). The lapack_lite functions such as dgeev and co are > standard python function (with *self and *args args, i.e. wrappers > around the underlying 'true' lapack function). Thanks, David. My question was because Sturla's language seemed to suggest (at least it did to me) that there was some python object foo where foo._cpointer would be a poniter to the raw C function one could then manipulate with ctypes. Perhaps I just misunderstood, but thanks for clarifying that at least this isn't possible today from pure python. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Vector interpolation on a 2D grid (with realistic results)
>2009/11/8 Pierre GM : > Chris, I gonna poke around and try to find some kriging algorithms. > I'll report in a few. In the meantime, if anybody has anythng already > implemented, please just let us know. A little late with the reply. I've used gstat (http://www.gstat.org/) in two ways 1) by running the executable from Python using os.system() and 2) using the rpy interface to the gstat R package. It's a little clunky but works and is quick and easy to set up. If you need to see some code for option 2 I can dig it up. You might also look at SGEMS http://sgems.sourceforge.net/ there is a Python interface, but I haven't used it. Cheers, Scott ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Use-case for np.choose
On Mon, Nov 9, 2009 at 7:59 PM, wrote: > On Mon, Nov 9, 2009 at 7:54 PM, David Goldsmith > wrote: >> May I infer from the sudden silence that I finally have it? > > I think so, > I assume that the result of broadcasting is unique, I haven't seen an > example yet where broadcasting would depend on the sequence in which > it is done. on a related note: I looked at the doc editor discussion for numpy.where and it seems broadcasting has been fixed also for where (in 1.3.0). I don't know whether the c implementation is related to choose. I only tried Paulis example. Josef > > Josef > > >> >> DG >> >> On Sun, Nov 8, 2009 at 8:50 PM, David Goldsmith >> wrote: >>> >>> OK, let me see if I'm interpreting this example correctly: >>> >>> >>> c1=np.arange(2).reshape(2,1,1); c1 >>> array([[[0]], >>> >>> [[1]]]) >>> >>> c2=2+np.arange(2).reshape(1,1,2); c2 >>> array([[[2, 3]]]) >>> >>> a=np.eye(2,dtype=int) >>> >>> np.choose(a, [c1, c2]) >>> array([[[2, 0], >>> [0, 3]], >>> >>> [[2, 1], >>> [1, 3]]]) >>> >>> First, everything is being broadcast to (2,2,2); a is broadcast to >>> [[[1,0], [0,1]], [[1,0], [0,1]]], c1 is broadcast to [[[0,0], [0,0]], >>> [[1,1], [1,1]]] and c2 is broadcast to [[[2,3], [2,3]], [[2,3], [2,3]]]. >>> Now result is created by "stepping through" broadcast a and using, >>> respectively, the positionally corresponding element from broadcast c1 >>> (resp. c2) if the value in a at the position is 0 (resp. 1). At least, this >>> gives the result above (but I have not examined other possible broadcasts of >>> the arguments to see if they would also give the result - I conjectured what >>> appeared to me to be the most "natural" broadcasts and checked to see if it >>> worked and it does; is there something I should know - e.g., uniqueness of >>> the result, or a rule governing how choose broadcasts - to *know* that the >>> broadcasts above are indeed the broadcasts choose is using?) >>> >>> Thanks again, >>> >>> DG >>> On Sun, Nov 8, 2009 at 8:19 PM, Anne Archibald >>> wrote: 2009/11/8 David Goldsmith : > On Sun, Nov 8, 2009 at 7:40 PM, Anne Archibald > > wrote: >> >> As Josef said, this is not correct. I think the key point of confusion >> is >> this: >> >> Do not pass choose two arrays. >> >> Pass it one array and a *list* of arrays. The fact that choices can be >> an array is a quirk we can't change, but you should think of the >> second argument as a list of arrays, > > Fine, but as you say, one *can* pass choose an array as the second > argument > and it doesn't raise an exception, so if someone is stupid/careless > enough > to pass an array for `choices`, how is choose interpreting it as a > list? Is > the first dimension "list converted" (so that, e.g., my (2,1,2) example > is > interpreted as a two element list, each of whose elements is a (1,2) > array)? It seems to me that this is the only reasonable interpretation, yes. After all, arrays behave like sequences along the first axis, whose elements are arrays of one less dimension. Thus if you pass an array, any broadcasting happens ignoring the first axis, which is a rather abnormal pattern for numpy broadcasting, but necessary here. As a bonus, I think this is what is implemented in current versions of numpy. (In 1.2.1 it raises an exception if broadcasting is necessary.) Anne ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Use-case for np.choose
On Mon, Nov 9, 2009 at 7:54 PM, David Goldsmith wrote: > May I infer from the sudden silence that I finally have it? I think so, I assume that the result of broadcasting is unique, I haven't seen an example yet where broadcasting would depend on the sequence in which it is done. Josef > > DG > > On Sun, Nov 8, 2009 at 8:50 PM, David Goldsmith > wrote: >> >> OK, let me see if I'm interpreting this example correctly: >> >> >>> c1=np.arange(2).reshape(2,1,1); c1 >> array([[[0]], >> >> [[1]]]) >> >>> c2=2+np.arange(2).reshape(1,1,2); c2 >> array([[[2, 3]]]) >> >>> a=np.eye(2,dtype=int) >> >>> np.choose(a, [c1, c2]) >> array([[[2, 0], >> [0, 3]], >> >> [[2, 1], >> [1, 3]]]) >> >> First, everything is being broadcast to (2,2,2); a is broadcast to >> [[[1,0], [0,1]], [[1,0], [0,1]]], c1 is broadcast to [[[0,0], [0,0]], >> [[1,1], [1,1]]] and c2 is broadcast to [[[2,3], [2,3]], [[2,3], [2,3]]]. >> Now result is created by "stepping through" broadcast a and using, >> respectively, the positionally corresponding element from broadcast c1 >> (resp. c2) if the value in a at the position is 0 (resp. 1). At least, this >> gives the result above (but I have not examined other possible broadcasts of >> the arguments to see if they would also give the result - I conjectured what >> appeared to me to be the most "natural" broadcasts and checked to see if it >> worked and it does; is there something I should know - e.g., uniqueness of >> the result, or a rule governing how choose broadcasts - to *know* that the >> broadcasts above are indeed the broadcasts choose is using?) >> >> Thanks again, >> >> DG >> On Sun, Nov 8, 2009 at 8:19 PM, Anne Archibald >> wrote: >>> >>> 2009/11/8 David Goldsmith : >>> > On Sun, Nov 8, 2009 at 7:40 PM, Anne Archibald >>> > >>> > wrote: >>> >> >>> >> As Josef said, this is not correct. I think the key point of confusion >>> >> is >>> >> this: >>> >> >>> >> Do not pass choose two arrays. >>> >> >>> >> Pass it one array and a *list* of arrays. The fact that choices can be >>> >> an array is a quirk we can't change, but you should think of the >>> >> second argument as a list of arrays, >>> > >>> > Fine, but as you say, one *can* pass choose an array as the second >>> > argument >>> > and it doesn't raise an exception, so if someone is stupid/careless >>> > enough >>> > to pass an array for `choices`, how is choose interpreting it as a >>> > list? Is >>> > the first dimension "list converted" (so that, e.g., my (2,1,2) example >>> > is >>> > interpreted as a two element list, each of whose elements is a (1,2) >>> > array)? >>> >>> It seems to me that this is the only reasonable interpretation, yes. >>> After all, arrays behave like sequences along the first axis, whose >>> elements are arrays of one less dimension. Thus if you pass an array, >>> any broadcasting happens ignoring the first axis, which is a rather >>> abnormal pattern for numpy broadcasting, but necessary here. >>> >>> As a bonus, I think this is what is implemented in current versions of >>> numpy. (In 1.2.1 it raises an exception if broadcasting is necessary.) >>> >>> Anne >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Use-case for np.choose
May I infer from the sudden silence that I finally have it? DG On Sun, Nov 8, 2009 at 8:50 PM, David Goldsmith wrote: > OK, let me see if I'm interpreting this example correctly: > > >>> c1=np.arange(2).reshape(2,1,1); c1 > array([[[0]], > >[[1]]]) > >>> c2=2+np.arange(2).reshape(1,1,2); c2 > array([[[2, 3]]]) > > >>> a=np.eye(2,dtype=int) > >>> np.choose(a, [c1, c2]) > array([[[2, 0], > [0, 3]], > >[[2, 1], > [1, 3]]]) > > First, everything is being broadcast to (2,2,2); a is broadcast to [[[1,0], > [0,1]], [[1,0], [0,1]]], c1 is broadcast to [[[0,0], [0,0]], [[1,1], [1,1]]] > and c2 is broadcast to [[[2,3], [2,3]], [[2,3], [2,3]]]. Now result is > created by "stepping through" broadcast a and using, respectively, the > positionally corresponding element from broadcast c1 (resp. c2) if the value > in a at the position is 0 (resp. 1). At least, this gives the result above > (but I have not examined other possible broadcasts of the arguments to see > if they would also give the result - I conjectured what appeared to me to be > the most "natural" broadcasts and checked to see if it worked and it does; > is there something I should know - e.g., uniqueness of the result, or a rule > governing how choose broadcasts - to *know* that the broadcasts above are > indeed the broadcasts choose is using?) > > Thanks again, > > DG > > On Sun, Nov 8, 2009 at 8:19 PM, Anne Archibald > wrote: > >> 2009/11/8 David Goldsmith : >> > On Sun, Nov 8, 2009 at 7:40 PM, Anne Archibald < >> peridot.face...@gmail.com> >> > wrote: >> >> >> >> As Josef said, this is not correct. I think the key point of confusion >> is >> >> this: >> >> >> >> Do not pass choose two arrays. >> >> >> >> Pass it one array and a *list* of arrays. The fact that choices can be >> >> an array is a quirk we can't change, but you should think of the >> >> second argument as a list of arrays, >> > >> > Fine, but as you say, one *can* pass choose an array as the second >> argument >> > and it doesn't raise an exception, so if someone is stupid/careless >> enough >> > to pass an array for `choices`, how is choose interpreting it as a >> list? Is >> > the first dimension "list converted" (so that, e.g., my (2,1,2) example >> is >> > interpreted as a two element list, each of whose elements is a (1,2) >> array)? >> >> It seems to me that this is the only reasonable interpretation, yes. >> After all, arrays behave like sequences along the first axis, whose >> elements are arrays of one less dimension. Thus if you pass an array, >> any broadcasting happens ignoring the first axis, which is a rather >> abnormal pattern for numpy broadcasting, but necessary here. >> >> As a bonus, I think this is what is implemented in current versions of >> numpy. (In 1.2.1 it raises an exception if broadcasting is necessary.) >> >> Anne >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release notes for arraysetops changes
ma, 2009-11-09 kello 23:13 +, Neil Crighton kirjoitti: > I've written some release notes (below) describing the changes to > arraysetops.py. If someone with commit access could check that these sound ok > and add them to the release notes file, that would be great. Thanks, added! Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Tue, Nov 10, 2009 at 4:08 AM, Jake VanderPlas wrote: >>The safe way to access them, since they are not exposed, is to call the >>function at the python level in your C code, but I don't think that's >>what you want, > > I want to avoid calling functions at the python level, because of the > overhead for multiple calls within nested loops. Yes, there is no question this would be useful, but we don't have the mechanism (yet) to make that possible. We have added some infrastructure at the build level to make C libraries available to 3rd parties, but more is needed for blas/lapack. > ...and directly call the BLAS fortran library. This pattern works on > my system (linux, using the system BLAS/LAPACK libraries). Is this a > form that will work across different OSs and different installs? Not at all. What you have done here is simply link against whatever blas/lapack is found on your system. It will not work on platforms without development package of blas/lapack, with different fortran name mangling, etc... That's certainly a valid option until we support this better in numpy/scipy, though. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Release notes for arraysetops changes
Hi, I've written some release notes (below) describing the changes to arraysetops.py. If someone with commit access could check that these sound ok and add them to the release notes file, that would be great. Cheers, Neil New features Improved set operations ~~~ In previous versions of NumPy some set functions (intersect1d, setxor1d, setdiff1d and setmember1d) could return incorrect results if the input arrays contained duplicate items. These now work correctly for input arrays with duplicates. setmember1d has been renamed to in1d, as with the change to accept arrays with duplicates it is no longer a set operation, and is conceptually similar to an elementwise version of the Python operator 'in'. All of these functions now accept the boolean keyword assume_unique. This is False by default, but can be set True if the input arrays are known not to contain duplicates, which can increase the functions' execution speed. Deprecations #. unique1d: use unique instead. unique1d raises a deprecation warning in 1.4, and will be removed in 1.5. #. intersect1d_nu: use intersect1d instead. intersect1d_nu raises a deprecation warning in 1.4, and will be removed in 1.5. #. setmember1d: use in1d instead. setmember1d raises a deprecation warning in 1.4, and will be removed in 1.5. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extremely bizarre behavior I just cant track down...
This problem is solved. Lisandro spent a bunch of time with me helping to track it down. Thanks Lisandro! On Mon, Nov 9, 2009 at 6:49 PM, Chris Colbert wrote: > I've got an issue where trying to pass a numpy array to one of my > cython functions fails, with the exception saying than 'int objects > are not iterable'. > > So somehow, my array is going from being perfectly ok (i can display > the image and print its shape and size), to going bad right before the > function call (i can still print the size and shape, but not the array > itself). > > I have pastebin'ed a couple of example cases showing the a workaround > and some failures that make absolutely no sense. > > http://pastebin.com/m65b0c718 > > Could one of the numpy geniuses here take a stab at what this could be? > > in the call to cvCvtColor() I create a new array which is returned as > grayimg, and I properly incref the dtype before the call to > PyArray_EMPY(). > > Cheers! > > Chris > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
>The safe way to access them, since they are not exposed, is to call the >function at the python level in your C code, but I don't think that's >what you want, I want to avoid calling functions at the python level, because of the overhead for multiple calls within nested loops. I may have a solution: I've managed to get access to the BLAS fortran library by using in the setup.py file: from distutils.core import Extension from numpy.distutils import system_info myextension = Extension(<...> library_dirs = system_info.blas_opt_info().get_lib_dirs(), <...>) Then in my C++ code I can declare, e.g. extern "C" double ddot_(const int *N, const double *DX, const int *INCX, const double *DY, const int *INCY); ...and directly call the BLAS fortran library. This pattern works on my system (linux, using the system BLAS/LAPACK libraries). Is this a form that will work across different OSs and different installs? -Jake ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] initializing an array of lists
Sat, 07 Nov 2009 21:56:29 -0600, alan wrote: > I want to build a 2D array of lists, and so I need to initialize the > array with empty lists : > > myarray = array([[[],[],[]] ,[[],[],[]]]) > > Is there a clever way to do this? I could define the array > > myarray = zeros( (xdim,ydim), dtype=object) and then iterate through the > elements initializing then to empty lists, but surely there is a better > way. This question seems to come up from time to time (= maybe should be a FAQ?). You can for example vectorize the list constructor: >>> filler = np.frompyfunc(lambda x: list(), 1, 1) >>> a = np.empty((3, 4), dtype=np.object) >>> filler(a, a); array([[[], [], [], []], [[], [], [], []], [[], [], [], []]], dtype=object) >>> a[0,3].append(9) >>> a array([[[], [], [], [9]], [[], [], [], []], [[], [], [], []]], dtype=object) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] initializing an array of lists
On Mon, Nov 9, 2009 at 12:00, Christopher Barker wrote: > a...@ajackson.org wrote: >> myarray = zeros( (xdim,ydim), dtype=object) >> and then iterate through the elements initializing then to empty lists, but >> surely there is a better way. > > I tried this: > > In [3]: a = np.empty((2,3), dtype=np.object) > > In [5]: a[:,:] = [] > > but got: > > ValueError: shape mismatch: objects cannot be broadcast to a single shape > > Is that a bug? Or is it simply too ambiguous for numpy to figure out > what the heck I want? The latter. In any case, you wouldn't want each element to be the same list object. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] initializing an array of lists
a...@ajackson.org wrote: > myarray = zeros( (xdim,ydim), dtype=object) > and then iterate through the elements initializing then to empty lists, but > surely there is a better way. I tried this: In [3]: a = np.empty((2,3), dtype=np.object) In [5]: a[:,:] = [] but got: ValueError: shape mismatch: objects cannot be broadcast to a single shape Is that a bug? Or is it simply too ambiguous for numpy to figure out what the heck I want? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Extremely bizarre behavior I just cant track down...
I've got an issue where trying to pass a numpy array to one of my cython functions fails, with the exception saying than 'int objects are not iterable'. So somehow, my array is going from being perfectly ok (i can display the image and print its shape and size), to going bad right before the function call (i can still print the size and shape, but not the array itself). I have pastebin'ed a couple of example cases showing the a workaround and some failures that make absolutely no sense. http://pastebin.com/m65b0c718 Could one of the numpy geniuses here take a stab at what this could be? in the call to cvCvtColor() I create a new array which is returned as grayimg, and I properly incref the dtype before the call to PyArray_EMPY(). Cheers! Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Who is ariver and why does it keep making test commits?
On Mon, Nov 9, 2009 at 09:08, Charles R Harris wrote: > Just curious, but there have been a lot of test commits to numpy svn by > ariver of the form: > > --- a/trunk/TEST_COMMIT > +++ b/trunk/TEST_COMMIT > @@ -15,3 +15,3 @@ > tim_hochberg: yes > > jarrod.millman: yes > -ariver: 2009.11.04.17.33.56 > +ariver: 2009.11.09.08.30.47 > > Which are 1) pointless, and 2) look almost automated. Anyone know what this > is about? Aaron River is our sysadmin. He is working on fixing the checkin mailing lists. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Who is ariver and why does it keep making test commits?
Just curious, but there have been a lot of test commits to numpy svn by ariver of the form: --- a/trunk/TEST_COMMIT +++ b/trunk/TEST_COMMIT @@ -15,3 +15,3 @@ tim_hochberg: yes jarrod.millman: yes -ariver: 2009.11.04.17.33.56 +ariver: 2009.11.09.08.30.47 Which are 1) pointless, and 2) look almost automated. Anyone know what this is about? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py function callback: error while using repeated arguments in function call
Yves Frederix wrote: > Hi, > > I am doing a simple function callback from fortran to python for which > the actual function call in fortran has repeated arguments. > > ! callback_error.f90: > subroutine testfun(x) >double precision, intent(in) :: x >double precision :: y > !f2py intent(callback) foo > !f2py double precision :: arg1 > !f2py double precision :: arg2 > !f2py double precision :: y > !f2py external y = foo(arg1, arg2) >external foo >y = foo(x, x) ! <-- this causes problems >print *, 'y:', y > end subroutine testfun .. > Is this expected behavior? No. The bug is now fixed in numpy svn (rev 7712). Thanks for pointing out this corner case. Pearu ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Vector interpolation on a 2D grid (with realistic results)
On Nov 7, 2009, at 9:14 PM, Ryan May wrote: > On Sat, Nov 7, 2009 at 5:38 PM, Pierre GM > wrote: >> Linear interpolation with the delaunay package doesn't work great for >> my data. I played with the radial basis functions, but I'm afraid >> they're leading me down the dark, dark path of parameter fiddling. In >> particular, I'm not sure how to prevent my interpolated values to be >> bounded by the min and max of my actual observations. >> Ralf' suggestion of smoothing the values afterwards is tempting, but >> sounds a bit too ad-hoc (btw, Ralf, those were relative differences >> of >> monthly average precipitation between El Niño and Neutral phases for >> November). > > That was me, not Ralf. :) Oopsie, sorry about that... > And I agree, I the interpolated field does > look a bit noisy for such data. I've been doing the smoothing on top > of natural neighbor for doing some of my own meteorological analysis. > Using the Gaussian kernel isn't really *that* ad hoc considering the > prevalence of Barnes/Cressman weighting for spatial averaging > typically used in meteorology. And if you have no idea what I'm > talking about, Google them, and you'll see. :) I gonna give it a try, thx for the suggestion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
Fernando Perez wrote: > On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: > >> You find a C function pointer wrapped in a CObject in the ._cpointer >> attribute. >> > > Sorry, in the ._cpointer attribute of what precisely? If Sturla refers to CObject as defined in the python C API, then the underlying lapack functions are not wrapped into a C object (this is not done automatically). The lapack_lite functions such as dgeev and co are standard python function (with *self and *args args, i.e. wrappers around the underlying 'true' lapack function). The safe way to access them, since they are not exposed, is to call the function at the python level in your C code, but I don't think that's what you want, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
