Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread David Cournapeau
On Tue, Oct 28, 2014 at 5:24 AM, Sturla Molden wrote: > Matthew Brett wrote: > > > Is this an option for us? Aren't we a little behind the performance > > curve on FFT after we lost FFTW? > > It does not run on Windows because it uses POSIX to allocate executable > memory for tasklets, as i und

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Sturla Molden
Matthew Brett wrote: > Is this an option for us? Aren't we a little behind the performance > curve on FFT after we lost FFTW? It does not run on Windows because it uses POSIX to allocate executable memory for tasklets, as i understand it. By the way, why did we loose FFTW, apart from GPL? One

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Sturla Molden
wrote: https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13";>https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13 >doesn't seem to mind mixing numpy and scipy (quick github search

[Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)

2014-10-27 Thread Nathaniel Smith
On 28 Oct 2014 04:07, "Matthew Brett" wrote: > > Hi, > > On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden wrote: > > Sturla Molden wrote: > > > >> If we really need a > >> kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or > >> Apple's Accelerate Framework, > > > > I should perha

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Matthew Brett
Hi, On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden wrote: > Sturla Molden wrote: > >> If we really need a >> kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or >> Apple's Accelerate Framework, > > I should perhaps also mention FFTS here, which claim to be faster than FFTW > and

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread josef.pktd
On Mon, Oct 27, 2014 at 11:31 PM, wrote: > > > On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden > wrote: > >> wrote: >> >> > For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, >> > partially?) >> >> No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy >> us

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread josef.pktd
On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden wrote: > wrote: > > > For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, > > partially?) > > No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy > uses a smaller C library called fftpack_lite. Algorithmically

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Sturla Molden
Sturla Molden wrote: > If we really need a > kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or > Apple's Accelerate Framework, I should perhaps also mention FFTS here, which claim to be faster than FFTW and has a BSD licence: http://anthonix.com/ffts/index.html

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Sturla Molden
wrote: > For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, > partially?) No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy uses a smaller C library called fftpack_lite. Algorithmically they are are similar, but fftpack_lite has fewer features (e.g. no D

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread josef.pktd
On Mon, Oct 27, 2014 at 2:24 PM, Eelco Hoogendoorn < hoogendoorn.ee...@gmail.com> wrote: > The same occurred to me when reading that question. My personal opinion is > that such functionality should be deprecated from numpy. I don't know who > said this, but it really stuck with me: but the power

Re: [Numpy-discussion] Why ndarray provides four ways to flatten?

2014-10-27 Thread Yuxiang Wang
Hi Alexander, In my opinion - because they don't do the same thing, especially when you think in terms in lower-level. ndarray.flat returns an iterator; ndarray.flatten() returns a copy; ndarray.ravel() only makes copies when necessary; ndarray.reshape() is more general purpose, even though you c

[Numpy-discussion] Why ndarray provides four ways to flatten?

2014-10-27 Thread Alexander Belopolsky
Given an n-dim array x, I can do 1. x.flat 2. x.flatten() 3. x.ravel() 4. x.reshape(-1) Each of these expressions returns a flat version of x with some variations. Why does NumPy implement four different ways to do essentially the same thing? ___ NumPy

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread Sturla Molden
Robert Kern wrote: > Please stop haranguing the new guy for not knowing things that you > know. I am not doing any of that. You are the only one haranguing here. I usually ignore your frequent inpolite comments, but I will do an exception this time and ask you to shut up. Sturla _

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread Robert Kern
On Mon, Oct 27, 2014 at 4:27 PM, Sturla Molden wrote: > Glen Mabey wrote: > >> I chose swig after reviewing the options listed here, and I didn't see >> cython on the list: >> >> http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html > > It's because that list is old and has not been up

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread Eelco Hoogendoorn
The same occurred to me when reading that question. My personal opinion is that such functionality should be deprecated from numpy. I don't know who said this, but it really stuck with me: but the power of numpy is first and foremost in it being a fantastic interface, not in being a library. There

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread MinRK
> > It's because that list is old and has not been updated. It has the > predecessor to Cython, Pyrex, but they are very different now. > > Both SciPy and NumPy has Cython as a build dependency, and also projects > like scikit-learn, scikit-image, statsmodels. > > If you find C++ projects which use

Re: [Numpy-discussion] multi-dimensional c++ proposal

2014-10-27 Thread Sturla Molden
On 27/10/14 13:14, Neal Becker wrote: > The multi-dimensional c++ stuff is interesting (about time!) > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf OMG, that API is about as awful as it gets. Obviously it is written by two computer scientists who do not understand what scie

[Numpy-discussion] ODE how to?

2014-10-27 Thread Vincent Davis
It's been too long since I have done differential equations and I am not sure the best tools to solve this problem. I am starting with a basic kinematic equation for the balance of forces. P\v - ((A*Cw*Rho*v^2)/2 + m*g*Crl + m*g*slope) = m*a P: power x: position v: velocity, x' a: acceleration x"

Re: [Numpy-discussion] [EXTERNAL] Re: numpy.i and std::complex

2014-10-27 Thread Sturla Molden
Bill Spotz wrote: > Oops, I meant '"Cython" is its own language,' not "Python" (although > Python qualifies, too, just not in context). > > Also, Pyrex, listed in the c-info.python-as-glue.html page, was the > pre-cursor to Cython. But when it comes to interfacing NumPy, they are really not com

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread Sturla Molden
Glen Mabey wrote: > I chose swig after reviewing the options listed here, and I didn't see cython > on the list: > > http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html It's because that list is old and has not been updated. It has the predecessor to Cython, Pyrex, but they are ver

Re: [Numpy-discussion] [EXTERNAL] Re: numpy.i and std::complex

2014-10-27 Thread Bill Spotz
Oops, I meant '"Cython" is its own language,' not "Python" (although Python qualifies, too, just not in context). Also, Pyrex, listed in the c-info.python-as-glue.html page, was the pre-cursor to Cython. -Bill On Oct 27, 2014, at 10:20 AM, Bill Spotz wrote: > Python is its own language, but

Re: [Numpy-discussion] [EXTERNAL] Re: numpy.i and std::complex

2014-10-27 Thread Bill Spotz
Python is its own language, but it allows you to import C and C++ code, thus creating an interface to these languages. Just as with SWIG, you would import a module written in Cython that gives you access to underlying C/C++ code. Cython is very nice for a lot of applications, but it is not the

Re: [Numpy-discussion] [EXTERNAL] Fwd: numpy.i and std::complex

2014-10-27 Thread Bill Spotz
Glen, Supporting std::complex<> was just low enough priority for me that I decided to wait until someone expressed interest ... and now, many years later, someone finally has. I would be happy to include this into numpy.i, but I would like to see some tests in the numpy repository demonstratin

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread Glen Mabey
On Oct 27, 2014, at 10:45 AM, Sturla Molden wrote: > Glen Mabey wrote: > >> I'd really like for this to be included alongside numpy.i -- but maybe I >> overestimate the number of numpy users who use complex data (let your >> voice be heard!) and who also end up using std::complex in C++ land.

[Numpy-discussion] Accept numpy arrays on arguments of numpy.testing.assert_approx_equal()

2014-10-27 Thread Edison Gustavo Muenz
I’ve implemented support for numpy.arrays for the arguments of numpy.testing.assert_approx_equal() and have issued a pull-request on Github. I don’t know if I should be sending the message to the list to notify about this, but since I’m new to the *numpy-

Re: [Numpy-discussion] numpy.i and std::complex

2014-10-27 Thread Sturla Molden
Glen Mabey wrote: > I'd really like for this to be included alongside numpy.i -- but maybe I > overestimate the number of numpy users who use complex data (let your > voice be heard!) and who also end up using std::complex in C++ land. I don't think you do. But perhaps you overestimate the numb

[Numpy-discussion] Fwd: numpy.i and std::complex

2014-10-27 Thread Glen Mabey
Hello, I was very excited to learn about numpy.i for easy numpy+swigification of C code -- it's really handy. Knowing that swig wraps C code, I wasn't too surprised that there was the issue with complex data types (as described at http://docs.scipy.org/doc/numpy/reference/swig.interface-file.h

[Numpy-discussion] Choosing between NumPy and SciPy functions

2014-10-27 Thread D. Michael McFarland
A recent post raised a question about differences in results obtained with numpy.linalg.eigh() and scipy.linalg.eigh(), documented at http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.eigh.html#numpy.linalg.eigh and http://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.eig

[Numpy-discussion] multi-dimensional c++ proposal

2014-10-27 Thread Neal Becker
The multi-dimensional c++ stuff is interesting (about time!) http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf -- -- Those who don't understand recursion are doomed to repeat it ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.

Re: [Numpy-discussion] higher accuracy in diagonialzation

2014-10-27 Thread Daπid
On 27 October 2014 09:37, Sunghwan Choi wrote: > One of them is inaccurate or both two of them are inaccurate within that > range. Which one is more accurate? You can check it yourself using the eigenvectors. The cosine distance between v and M.dot(v) will give you the error in the eigenvectors

Re: [Numpy-discussion] ANN: NumPy 1.9.1 release candidate

2014-10-27 Thread Jens Nielsen
Thanks Julian, Just confirming that this (as expected) solves the issues that we have seen with gradient in Matplotlib with 1.9.0 best regards Jens On Sun, Oct 26, 2014 at 5:13 PM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > Hi, > > We have finally finished the first release cand

Re: [Numpy-discussion] higher accuracy in diagonialzation

2014-10-27 Thread Stefan van der Walt
On 2014-10-27 10:37:58, Sunghwan Choi wrote: > I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods, > scipy.linalg.eigh and numpy.linalg.eigh give significantly different result. > The results from two methods are different within 10^-4 order. One of them > is inaccurate or b

[Numpy-discussion] higher accuracy in diagonialzation

2014-10-27 Thread Sunghwan Choi
Dear all, I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods, scipy.linalg.eigh and numpy.linalg.eigh give significantly different result. The results from two methods are different within 10^-4 order. One of them is inaccurate or both two of them are inaccurate within that