David Cournapeau wrote:
On Dec 12, 2007 2:58 AM, Christopher Barker <Chris.Barker@noaa.gov> wrote:
I think this idea is the way to go (maybe along with an ACML build, but my limited testing seemed to indicate that MKL works on AMD CPUs).
I am personally totally against it. It is one thing to support proprietary software, that's quite another to build our official binaries against it. I consider myself far from any kind of open source zealot, but that would be crossing a line I would much prefer avoiding to cross. Interesting -- I DO consider myself a kind of Open Source Zealot -- and
David Cournapeau wrote: this doesn't bother me a bit.
It would bother me a LOT if numpy could only be built against this lib, and not an Open Source one -- but I don't see this as any different than providing a binary built with the Microsoft compiler.
For me it is: when using a MS compiler, you are not forcing people to use a non open source product (except maybe the C runtime). What will happen if we offer binaries using MKL ? The ATLAS will not be tested anymore on windows, it forces every developer to use the MKL to support it.... At least, now, with atlas problems, I can reproduce the problems. With the MKL, not so much.
I agree. The official-official Win32 binaries (numpy-<version>-py<pyversion>.msi and numpy-<version>-py<pyversion>-win32.egg on the SourceForge donwload page) should be unencumbered. Other versions can be on the download page, too, but they should be named differently, like numpy-mkl-<version>-... . -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco