On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith n...@pobox.com wrote:
On 28 Oct 2014 04:07, Matthew Brett matthew.br...@gmail.com wrote:
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
On Thu, Dec 11, 2014 at 10:41 AM, Todd toddr...@gmail.com wrote:
On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith n...@pobox.com wrote:
On 28 Oct 2014 04:07, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore e...@redtetrahedron.org wrote:
On Thu, Dec 11, 2014 at 10:41 AM, Todd toddr...@gmail.com wrote:
I recently became aware of another C-library for doing FFTs (and other
things):
https://github.com/arrayfire/arrayfire
They claim to have comparable
On Thu, Dec 11, 2014 at 4:55 PM, Robert Kern robert.k...@gmail.com wrote:
On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore e...@redtetrahedron.org
wrote:
On Thu, Dec 11, 2014 at 10:41 AM, Todd toddr...@gmail.com wrote:
I recently became aware of another C-library for doing FFTs (and other
On 30 Oct 2014 03:58, Sturla Molden sturla.mol...@gmail.com wrote:
[...]
We cannot bundle NumPy or SciPy binaries with FFTW due to GPL [*], but
as I understand it we already have permission from Intel to bundle
binary wheels linked with MKL. Accelerate is a system library, so that
does not
On 30/10/14 03:58, Sturla Molden wrote:
MKL has an API compatible with FFTW, so FFTW and MKL can be supported
with the same C code.
Compatible with big caveats:
https://software.intel.com/en-us/node/522278
Henry
___
NumPy-Discussion mailing list
Nathaniel Smith n...@pobox.com wrote:
[*] Actually, we could, but the binaries would be tainted with a viral
license.
And binaries linked with MKL are tainted by a proprietary license... They
have very similar effects,
The MKL license is proprietary but not viral.
Sturla
On Thu, Oct 30, 2014 at 11:11 AM, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
[*] Actually, we could, but the binaries would be tainted with a viral
license.
And binaries linked with MKL are tainted by a proprietary license... They
have very similar
On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
[*] Actually, we could, but the binaries would be tainted with a viral
license.
And binaries linked with MKL are tainted by a proprietary license...
They
have very similar effects,
I think that numpy.fft should be left there in its current state
(although perhaps as deprecated). Now scipy.fft should have a good generic
algorithm as default, and easily allow for different implementations to be
accessed through the same interface.
I also agree with the above. But I want to
On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith n...@pobox.com wrote:
On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
[*] Actually, we could, but the binaries would be tainted with a viral
license.
And binaries linked with MKL
On Thu, Oct 30, 2014 at 10:24 AM, Matthew Brett matthew.br...@gmail.com wrote:
On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith n...@pobox.com wrote:
On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
[*] Actually, we could, but the
My point isn't about speed; its about the scope of numpy. typing np.fft.fft
isn't more or less convenient than using some other symbol from the
scientific python stack.
Numerical algorithms should be part of the stack, for sure; but should they
be part of numpy? I think its cleaner to have them
On 29 October 2014 10:48, Eelco Hoogendoorn hoogendoorn.ee...@gmail.com wrote:
My point isn't about speed; its about the scope of numpy. typing np.fft.fft
isn't more or less convenient than using some other symbol from the
scientific python stack.
The problem is in distribution. For many
On Wed, Oct 29, 2014 at 9:48 AM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
My point isn't about speed; its about the scope of numpy. typing
np.fft.fft isn't more or less convenient than using some other symbol from
the scientific python stack.
Numerical algorithms should be part
Id rather have us discuss how to facilitate the integration of as
many possible fft libraries with numpy behind a maximally uniform
interface, rather than having us debate which fft library is 'best'.
I agree with the above.
I would agree if it were not already there, but removing it (like
On 29/10/14 18:23, Alexander Eberspächer wrote:
Definitely. My attempt at streamlining the use of pyfftw even further
can be found here:
https://github.com/aeberspaecher/transparent_pyfftw
There could be an argument that this sort of capability should be added
to the pyfftw package, as a
On 29.10.2014 19:40, Henry Gomersall wrote:
There could be an argument that this sort of capability should be added
to the pyfftw package, as a package level config.
Something like:
import pyfftw
pyfftw.default_threads = 4
I think that would be great, though probably slightly off-topic
On 29/10/14 10:48, Eelco Hoogendoorn wrote:
Id rather have us discuss how to facilitate the integration of
as many possible fft libraries with numpy behind a maximally uniform
interface, rather than having us debate which fft library is 'best'.
I am happy with the NumPy interface. There
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com wrote:
It's definitely attractive. Some potential issues that might need dealing
with, based on a quick skim:
In my tests, numpy's FFTPACK isn't that bad considering
* (virtually) no extra overhead for installation
*
On Tue, Oct 28, 2014 at 1:32 AM, Jerome Kieffer jerome.kief...@esrf.fr
wrote:
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com wrote:
It's definitely attractive. Some potential issues that might need dealing
with, based on a quick skim:
In my tests, numpy's FFTPACK isn't
On Tue, Oct 28, 2014 at 9:19 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, Oct 28, 2014 at 1:32 AM, Jerome Kieffer jerome.kief...@esrf.fr
wrote:
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com wrote:
It's definitely attractive. Some potential issues
On 28/10/14 09:41, David Cournapeau wrote:
The real issue with fftw (besides the license) is the need for plan
computation, which are expensive (but are not needed for each
transform). Handling this in a way that is user friendly while
tweakable for advanced users is not easy, and IMO more
On 28/10/14 04:28, Nathaniel Smith wrote:
- not sure if it can handle non-power-of-two problems at all, or at
all efficiently. (FFTPACK isn't great here either but major
regressions would be bad.)
From my reading, this seems to be the biggest issue with FFTS (from my
reading as well) and
Jerome Kieffer jerome.kief...@esrf.fr wrote:
Because the plan creation was taking ages with FFTw, numpy's FFTPACK was
often faster (overall)
Matlab switched from FFTPACK to FFTW because the latter was faster in
general. If FFTW guesses a plan it does not take very long. Actual
measurements can
David Cournapeau courn...@gmail.com wrote:
The real issue with fftw (besides the license) is the need for plan
computation, which are expensive (but are not needed for each transform).
This is not a problem if you thell FFTW to guess a plan instead of making
measurements. FFTPACK needs to set
On 28 Oct 2014 07:32, Jerome Kieffer jerome.kief...@esrf.fr wrote:
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com wrote:
It's definitely attractive. Some potential issues that might need
dealing
with, based on a quick skim:
In my tests, numpy's FFTPACK isn't that bad
If I may 'hyjack' the discussion back to the meta-point:
should we be having this discussion on the numpy mailing list at all?
Perhaps the 'batteries included' philosophy made sense in the early days of
numpy; but given that there are several fft libraries with their own pros
and cons, and that
I
On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith n...@pobox.com wrote:
On 28 Oct 2014 07:32, Jerome Kieffer jerome.kief...@esrf.fr wrote:
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com wrote:
It's definitely attractive. Some potential issues that might need
On 28 Oct 2014 14:48, Eelco Hoogendoorn hoogendoorn.ee...@gmail.com
wrote:
If I may 'hyjack' the discussion back to the meta-point:
should we be having this discussion on the numpy mailing list at all?
Of course we should.
Perhaps the 'batteries included' philosophy made sense in the early
On Tue, Oct 28, 2014 at 3:06 PM, David Cournapeau courn...@gmail.com
wrote:
I
On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith n...@pobox.com wrote:
On 28 Oct 2014 07:32, Jerome Kieffer jerome.kief...@esrf.fr wrote:
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith n...@pobox.com
Eelco Hoogendoorn hoogendoorn.ee...@gmail.com wrote:
Perhaps the 'batteries included' philosophy made sense in the early days of
numpy; but given that there are several fft libraries with their own pros
and cons, and that most numpy projects will use none of them at all, why
should numpy
On 28/10/14 16:50, David Cournapeau wrote:
Nothing impossible (looks like Sony at least uses this code on windows:
https://github.com/anthonix/ffts/issues/27#issuecomment-40204403), but
not a 2 hours thing either.
One of the downsides of the BSD license :)
Cheers,
Daniele
On 2014-10-28 19:37:17, Daniele Nicolodi dani...@grinta.net wrote:
On 28/10/14 16:50, David Cournapeau wrote:
Nothing impossible (looks like Sony at least uses this code on windows:
https://github.com/anthonix/ffts/issues/27#issuecomment-40204403), but
not a 2 hours thing either.
One of the
On 28/10/14 18:44, Stefan van der Walt wrote:
On 2014-10-28 19:37:17, Daniele Nicolodi dani...@grinta.net wrote:
On 28/10/14 16:50, David Cournapeau wrote:
Nothing impossible (looks like Sony at least uses this code on windows:
https://github.com/anthonix/ffts/issues/27#issuecomment-40204403),
On 2014-10-28 19:55:57, Daniele Nicolodi dani...@grinta.net wrote:
On 28/10/14 18:44, Stefan van der Walt wrote:
On 2014-10-28 19:37:17, Daniele Nicolodi dani...@grinta.net wrote:
On 28/10/14 16:50, David Cournapeau wrote:
Nothing impossible (looks like Sony at least uses this code on windows:
36 matches
Mail list logo
