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
