Re: [Numpy-discussion] np.linalg.norm terrible behavior

e accuracy > > x=(np.array([1]*1 + [1e4], dtype=np.float32)) > np.sum(x*x) > 1.0001e+08 > > You can sort x from small numbers to bigger numbers before you call sum. > > -Kibeom Kim > > On Sat, Mar 5, 2011 at 6:27 PM, Xavier Gnata <mailto:xavier.gn...@gmail.com>

[Numpy-discussion] np.linalg.norm terrible behavior

Hi, I got this problem in a real life code and it took me some time to figure out that np.linalg.norm has a terrible numerical behavior. The problem is nicely described here http://fseoane.net/blog/2011/computing-the-vector-norm/ numpy/linalg/linalg.py claims to be a "high-level Python interfac

Re: [Numpy-discussion] Gauss-Newton Method in Python?

Let (Xi,Yi) be the positions of your stars on the sky. i in the 1 to N range. Let (Xj,Yj) be the positions of your stars images (PSF) on your picture. i in the 1 to N range. You can parametrize the distortion this way: Xj_param = Px(Xi,Yi) Yj_param = Py(Xi,Yi) where Px and Py are the two polynomial

Re: [Numpy-discussion] Speedup a code using apply_along_axis

On 02/28/2010 08:17 PM, josef.p...@gmail.com wrote: > On Sun, Feb 28, 2010 at 1:51 PM, Xavier Gnata wrote: > >> Hi, >> >> I'm sure I reinventing the wheel with the following code: >> from numpy import * >> from scipy import polyfit,stats >> >&g

[Numpy-discussion] Speedup a code using apply_along_axis

Hi, I'm sure I reinventing the wheel with the following code: from numpy import * from scipy import polyfit,stats def f(x,y,z): return x+y+z M=fromfunction(f,(2000,2000,10)) def foo(M): ramp=where(M<1000)[0] l=len(ramp) t=arange(l) if(l>1): return polyfit(t,ramp,1)[0]

Re: [Numpy-discussion] Python 3 porting

Hi, Do you plan to make some noise about that when numpy2.0 will be release? IMHO you should. Do you for instance plan to have a clear announcement on the scipy web site? Xavier > Hi, > > The test suite passes now on Pythons 2.4 - 3.1. Further testing is very > welcome -- also on Python 2.x. Plea

Re: [Numpy-discussion] Python 3 porting

New try new error: gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-3.1/numpy/core/src/multiarray/multiarraymodule_onefile.o -Lbuild/temp.linux-x86_64-3.1 -lnpymath -lm -o build/lib.linux-x86_64-3.1/numpy/core/multiarray.so /usr/bin/ld: build/temp.linux-x86_64-3.1/numpy

Re: [Numpy-discussion] numpy 2.0, what else to do?

numpy/core/src/multiarray/multiarraymodule_onefile.o" failed with exit status 1 BTW, is there a better place to discuss these "python3 only" related issues? Xavier > Xavier Gnata gmail.com> writes: > >> Well I ran git clone git://github.com/pv/numpy-work.git an

Re: [Numpy-discussion] numpy 2.0, what else to do?

On 02/13/2010 09:28 PM, Pauli Virtanen wrote: > We will most likely have experimental py3 support in 2.0. > > If you, or someone else wishes to help bringing 2.0 to fully work with Py3, > now is a very good time to step up. > > How to give a hand: > > 1. Get my latest py3 branch from http://github

Re: [Numpy-discussion] numpy 2.0, what else to do?

On 02/13/2010 10:15 PM, Charles R Harris wrote: > > > On Sat, Feb 13, 2010 at 2:07 PM, Xavier Gnata <mailto:xavier.gn...@gmail.com>> wrote: > > On 02/13/2010 09:28 PM, Pauli Virtanen wrote: > > We will most likely have experimental py3 support in 2.0. >

Re: [Numpy-discussion] numpy 2.0, what else to do?

On 02/13/2010 09:28 PM, Pauli Virtanen wrote: > We will most likely have experimental py3 support in 2.0. > > If you, or someone else wishes to help bringing 2.0 to fully work with Py3, > now is a very good time to step up. > > How to give a hand: > > 1. Get my latest py3 branch from http://github

Re: [Numpy-discussion] numpy 2.0, what else to do?

IMHO 2.0 should support python3. That would be a major step and a good reason to call it 2.0. Xavier > This is exactly what I was worried about with calling the next release > 2.0. > > This is not the time to change all the things we wish were done > differently. > > The release is scheduled

Re: [Numpy-discussion] numpy 2.0, what else to do?

On 02/13/2010 07:31 PM, Charles R Harris wrote: > > > On Sat, Feb 13, 2010 at 11:23 AM, Joe Harrington > wrote: > > Chuck Harris writes (on numpy-discussion): > > > Since there has been talk of deprecating the numarray and numeric > > compatibility parts of

Re: [Numpy-discussion] Lots of 32bits specific errors

> On Wed, Jan 6, 2010 at 6:48 AM, Xavier Gnata wrote: > >> Hi, >> >> I have compiled numpy 1.5.0.dev8039 both on a 32 and a 64bits ubuntu >> machine. >> >> On the 64bits one, everything is fine: >> numpy.test get a perfect score: >>

[Numpy-discussion] Lots of 32bits specific errors

Hi, I have compiled numpy 1.5.0.dev8039 both on a 32 and a 64bits ubuntu machine. On the 64bits one, everything is fine: numpy.test get a perfect score: On the 32bits ubuntu, the story is not that nice: ERROR: Test filled w/ mvoid -

[Numpy-discussion] Help to port numpy to python3?

Hi, Is there a way to help to port numpy to python3? I don't thing I have time to rewrite some code but I can test whatever has to be tested. Is there an official web page showing the status of this port? Same question from scipy? It is already nice to see that the last numpy version is compatib

Re: [Numpy-discussion] Best way to insert C code in numpy code

René Dudfield wrote: > On Mon, Sep 21, 2009 at 8:12 PM, David Warde-Farley > wrote: > >> On 21-Sep-09, at 2:55 PM, Xavier Gnata wrote: >> >> >>> Should I read that to learn you cython and numpy interact? >>> Or is there another best docume

Re: [Numpy-discussion] Best way to insert C code in numpy code

David Cournapeau wrote: > Xavier Gnata wrote: > >> Hi, >> >> I have a large 2D numpy array as input and a 1D array as output. >> In between, I would like to use C code. >> C is requirement because it has to be fast and because the algorithm >> cannot

[Numpy-discussion] Best way to insert C code in numpy code

Hi, I have a large 2D numpy array as input and a 1D array as output. In between, I would like to use C code. C is requirement because it has to be fast and because the algorithm cannot be written in a numpy oriented way :( (no way...really). Which tool should I use to achieve that? waeve.inline

Re: [Numpy-discussion] block matrix and sums of blocks

Robert Kern wrote: > On Sun, Feb 22, 2009 at 19:39, Xavier Gnata wrote: > >> Hi, >> >> Let us consider one kN x kM array. >> What is the fastest way to sum each k x k square block of A and to put >> all these results into a NxM array B? >> >&g

[Numpy-discussion] block matrix and sums of blocks

Hi, Let us consider one kN x kM array. What is the fastest way to sum each k x k square block of A and to put all these results into a NxM array B? For instance: If A = [112233 112233 223311 223311] then B = [4 8 12 4 12 4] No sanity checks on the arrays shapes are requiered. Only speed mat

Re: [Numpy-discussion] Numpy performance vs Matlab.

Well it is the best pitch for numpy versus matlab I have read so far :) (and I 100% agree) Xavier > On 1/7/2009 4:16 PM, David Cournapeau wrote: > > >> I think on recent versions of matlab, there is nothing you can do >> without modifying the code: matlab has some JIT compilation for loops, >>

Re: [Numpy-discussion] fast matrix vector operations

> Suppose I have a toeplitz matrix, A. There is a well known algorithm > for computing the matrix vector product Ax, in NlogN operations. An > exact reference escapes me, but it may be in Golub & van Loan's book. > > My question is, how could I best take advantage of this algorithm > withi

Re: [Numpy-discussion] Different results from repeated calculation, part 2

Alok Singhal wrote: > On 14/08/08: 10:20, Keith Goodman wrote: > >> A unit test is attached. It contains three tests: >> >> In test1, I construct matrices x and y and then repeatedly calculate z >> = calc(x,y). The result z is the same every time. So this test passes. >> >> In test2, I construct

Re: [Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

gt; On 9/4/07, David Goldsmith <[EMAIL PROTECTED]> wrote: >> >> >>> Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array >>> typemap to share? Thanks! >>> >>> DG >>> -- >>> ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyres

Re: [Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

Christopher Barker wrote: > Xavier Gnata wrote: > >> Here it is :) >> > > Thanks, that's helpful. Am I reading it right? Are you running the > python process embedded in your C++ app? (rather than extending?) > > Yes! The point is this way I&#x

Re: [Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

al performance differences between vector and valarray (in my use cases...) -- Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: [EMAIL PROTECTED] ###

Re: [Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

Christopher Barker wrote: > Xavier Gnata wrote: > >> I'm using the numpy C API (PyArray_SimpleNewFromData) to perform the >> conversion but my code is written by hands. >> > > I'd like to see that. How are you getting the pointer to pass in to &g

Re: [Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?

umpy-discussion@scipy.org >> http://projects.scipy.org/mailman/listinfo/numpy-discussion >> > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > > ___ > Numpy-discussion mailing list > Numpy-discussion@s

Re: [Numpy-discussion] Wrong lapack version detection (32/64bits)

Pearu Peterson wrote: > Xavier Gnata wrote: > > >> I just would like to be able to tell numpy to use liblapack.so instead >> of this non free libmkl_lapack32.so >> > > For that set the following environment variable when building numpy/scipy: > &

Re: [Numpy-discussion] Wrong lapack version detection (32/64bits)

s / week) on Ubuntu without problems. > >> ImportError: >> /usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so: undefined >> symbol: zgesdd_ >> >> Looks like the procedure to detect the lapack version is fully buggy (or >> maybe the lapack debia

Re: [Numpy-discussion] Wrong lapack version detection (32/64bits)

Xavier Gnata wrote: > Hi, > > I'm trying to update numpy by compiling the up to date svn: > > I get this error : > gcc: numpy/linalg/lapack_litemodule.c > gcc -pthread -shared > build/temp.linux-i686-2.4/numpy/linalg/lapack_litemodule.o > -lmkl_lapack32 -l

[Numpy-discussion] Wrong lapack version detection (32/64bits)

e lapack64 installed on this i386 machine. I have try to simply fix that in the config file of numpy replacing lapack64 by lapack32 everywhere but it fails (and it is not an acceptable fix). Can anyone reproduce that?? Xavier -- ######## Xavier Gnata CRAL -

Re: [Numpy-discussion] Logical Selector

;not". >> >> > > except that their precedence is higher than that of the logical > operators, so one must remember to use parentheses: > (ad) > which is good for clarity anyway. > > Eric > Hi, Well maybe it is a bug on my box (thunderbird) but the

[Numpy-discussion] -lmkl_lapack64 on i368 ??

do not have lapack64 installed on this i386 machine. -- ######## Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-ma

Re: [Numpy-discussion] Efficient operator overloading

t be the same as in c++. Sorry if my message was not clear :(. What you want is symbolics maths with matrix and a way to trigger the evaluation. Well, as far as I have seen for now, it looks pretty hard to code that with a pythonic syntax and a way to report in case of errors. It is also pret

Re: [Numpy-discussion] Efficient operator overloading

on. As a result you cannot implement the way boost++ works : + * - / operators build a tree and all the loops are done in the = operator code. I do not say that it is impossible to code an efficient way to deal with operators and matrix in python but only that it looks not possible to match the

[Numpy-discussion] numpy.tests() FAILED (errors=3)

pes -- It should be a side effect of one patch because I can read things like " # !! This is actually (unexpectedly) zero" in /usr/lib/python2.4/site-packages/numpy/lib/tests/test_type_check.py Xavier. -- #

[Numpy-discussion] PyArray_FromDims segfault??

additionnal code but it is always almost the same :) -- #### Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85