On Thu, Dec 11, 2014 at 4:55 PM, Robert Kern wrote:
> On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore
> wrote:
> >
> > On Thu, Dec 11, 2014 at 10:41 AM, Todd wrote:
>
> >> I recently became aware of another C-library for doing FFTs (and other
> things):
> >>
> >> https://github.com/arrayfire/arrayf
On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore wrote:
>
> On Thu, Dec 11, 2014 at 10:41 AM, Todd 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 FFT performance to MKL when run
On Thu, Dec 11, 2014 at 10:41 AM, Todd wrote:
> On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith wrote:
>
>> 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 ne
On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith wrote:
> 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 lik
On Thu, Oct 30, 2014 at 10:24 AM, Matthew Brett wrote:
> On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith wrote:
>> On 30 Oct 2014 11:12, "Sturla Molden" wrote:
>>>
>>> Nathaniel Smith wrote:
>>>
>>> >> [*] Actually, we could, but the binaries would be tainted with a viral
>>> >> license.
>>> >
On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith wrote:
> On 30 Oct 2014 11:12, "Sturla Molden" wrote:
>>
>> Nathaniel Smith wrote:
>>
>> >> [*] Actually, we could, but the binaries would be tainted with a viral
>> >> license.
>> >
>> > And binaries linked with MKL are tainted by a proprietary l
> 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 a
On 30 Oct 2014 11:12, "Sturla Molden" wrote:
>
> Nathaniel Smith 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
On Thu, Oct 30, 2014 at 11:11 AM, Sturla Molden wrote:
> Nathaniel Smith 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 licen
Nathaniel Smith 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 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
Num
On 30 Oct 2014 03:58, "Sturla Molden" 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 pose a license proble
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 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
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 18:03, Pierre-Andre Noel 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 agree with the above.
Absolutely. I
>> 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 (lik
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
On 29 October 2014 10:48, Eelco Hoogendoorn 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 users, installing a new
librar
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 in
On 2014-10-28 19:55:57, Daniele Nicolodi wrote:
> On 28/10/14 18:44, Stefan van der Walt wrote:
>> On 2014-10-28 19:37:17, Daniele Nicolodi 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/an
On 28/10/14 18:44, Stefan van der Walt wrote:
> On 2014-10-28 19:37:17, Daniele Nicolodi 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
>>> n
On 2014-10-28 19:37:17, Daniele Nicolodi 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 downsides
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
Eelco Hoogendoorn 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 bundle any of them?
Because
On Tue, Oct 28, 2014 at 3:06 PM, David Cournapeau
wrote:
> I
>
> On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith wrote:
>
>> On 28 Oct 2014 07:32, "Jerome Kieffer" wrote:
>> >
>> > On Tue, 28 Oct 2014 04:28:37 +
>> > Nathaniel Smith wrote:
>> >
>> > > It's definitely attractive. Some pote
On 28 Oct 2014 14:48, "Eelco Hoogendoorn"
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 days
of numpy; but gi
I
On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith wrote:
> On 28 Oct 2014 07:32, "Jerome Kieffer" wrote:
> >
> > On Tue, 28 Oct 2014 04:28:37 +
> > Nathaniel Smith wrote:
> >
> > > It's definitely attractive. Some potential issues that might need
> dealing
> > > with, based on a quick ski
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 m
On 28 Oct 2014 07:32, "Jerome Kieffer" wrote:
>
> On Tue, 28 Oct 2014 04:28:37 +
> Nathaniel Smith 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
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).
This is not a problem if you thell FFTW to guess a plan instead of making
measurements. FFTPACK needs to set up a look-up tabl
Jerome Kieffer 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 be slow, however, bu
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)
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 mo
On Tue, Oct 28, 2014 at 9:19 AM, Charles R Harris wrote:
>
>
> On Tue, Oct 28, 2014 at 1:32 AM, Jerome Kieffer
> wrote:
>
>> On Tue, 28 Oct 2014 04:28:37 +
>> Nathaniel Smith wrote:
>>
>> > It's definitely attractive. Some potential issues that might need
>> dealing
>> > with, based on a qu
On Tue, Oct 28, 2014 at 1:32 AM, Jerome Kieffer
wrote:
> On Tue, 28 Oct 2014 04:28:37 +
> Nathaniel Smith 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
> * (v
On Tue, 28 Oct 2014 04:28:37 +
Nathaniel Smith 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
* (virtually) no plan cre
37 matches
Mail list logo
