Stefan van der Walt ste...@sun.ac.za writes:
On 2014-10-27 15:26:58, D. Michael McFarland dm...@dmmcf.net wrote:
What I would like to ask about is the situation this illustrates, where
both NumPy and SciPy provide similar functionality (sometimes identical,
to judge by the documentation). Is
Just to throw in my two cents here. I feel that sometimes, features are
tried out first elsewhere (possibly in scipy) and then brought down into
numpy after sufficient shakedown time. So, in some cases, I wonder if the
numpy version is actually more refined than the scipy version? Of course,
there
On Fri, Oct 31, 2014 at 11:07 AM, Benjamin Root ben.r...@ou.edu wrote:
Just to throw in my two cents here. I feel that sometimes, features are
tried out first elsewhere (possibly in scipy) and then brought down into
numpy after sufficient shakedown time. So, in some cases, I wonder if the
On Fri, Oct 31, 2014 at 3:07 PM, Benjamin Root ben.r...@ou.edu wrote:
Just to throw in my two cents here. I feel that sometimes, features are
tried out first elsewhere (possibly in scipy) and then brought down into
numpy after sufficient shakedown time. So, in some cases, I wonder if the
numpy
On Tue, Oct 28, 2014 at 5:24 AM, Sturla Molden sturla.mol...@gmail.com
wrote:
Matthew Brett matthew.br...@gmail.com 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
Hi Michael
On 2014-10-27 15:26:58, D. Michael McFarland dm...@dmmcf.net wrote:
What I would like to ask about is the situation this illustrates, where
both NumPy and SciPy provide similar functionality (sometimes identical,
to judge by the documentation). Is there some guidance on which is to
I would add one element to the discussion: for some (odd) reasons, SciPy is
lacking the functions `rfftn` and `irfftn`, functions using half the memory
space compared to their non-real equivalent `fftn` and `ifftn`. However, I
haven't (yet) seriously tested `scipy.fftpack.fftn` vs. `np.fft.rfftn`
Pierre Barbier de Reuille pie...@barbierdereuille.net wrote:
I would add one element to the discussion: for some (odd) reasons, SciPy is
lacking the functions `rfftn` and `irfftn`, functions using half the memory
space compared to their non-real equivalent `fftn` and `ifftn`.
In both NumPy
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.
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 of
josef.p...@gmail.com 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
Sturla Molden sturla.mol...@gmail.com 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:
On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
josef.p...@gmail.com 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
On Mon, Oct 27, 2014 at 11:31 PM, josef.p...@gmail.com wrote:
On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
josef.p...@gmail.com wrote:
For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft,
partially?)
No. SciPy uses the Fortran
Hi,
On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Sturla Molden sturla.mol...@gmail.com 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,
josef.p...@gmail.com wrote:
ahref=https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13;https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13/a
doesn't seem to mind mixing numpy and
Matthew Brett matthew.br...@gmail.com 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
17 matches
Mail list logo
