Hi All,
I have reached the point where I really need to get some sort of
optimised/accelerated BLAS/LAPACK for windows 64 so have been trying a few
different things out to see whether I can get anything usable, today i
stumbled across this:
http://icl.cs.utk.edu/lapack-for-windows/index.html
Has
David Cournapeau wrote:
> Michael Abshoff wrote:
Hi David,
>> Sure, but there isn't even a 32 bit gcc out there that can produce 64
>> bit PE binaries (aside from the MinGW fork that AFAIK does not work
>> particularly well and allegedly has issues with the cleanliness of some
>> of the code
Michael Abshoff wrote:
>
> Sure, but there isn't even a 32 bit gcc out there that can produce 64
> bit PE binaries (aside from the MinGW fork that AFAIK does not work
> particularly well and allegedly has issues with the cleanliness of some
> of the code which is allegedly the reason that the of
David Cournapeau wrote:
Hi David,
> Michael Abshoff wrote:
>> Well, I think that having a 64 bit native build of numpy/scipy using an
>> efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL)
>> can't be a bad thing :)
>
> Yes, of course. But it is useful to be able to use a 32
Michael Abshoff wrote:
>
> Well, I think that having a 64 bit native build of numpy/scipy using an
> efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL)
> can't be a bad thing :)
Yes, of course. But it is useful to be able to use a 32 bits toolchain
to produce 64 bits software
David Cournapeau wrote:
> Ravi wrote:
Hi,
>> Michael Abshoff already responded to the ATLAS question. I don't have access
>> to a 64-bit Windows. Given the volume of legacy 32-bit applications where I
>> work, there is no chance of 64-bit Windows access for me for at least 2
>> years.
>
> Win
Ravi wrote:
>
> Michael Abshoff already responded to the ATLAS question. I don't have access
> to a 64-bit Windows. Given the volume of legacy 32-bit applications where I
> work, there is no chance of 64-bit Windows access for me for at least 2 years.
Windows 64 actually has a very nice feature:
David Cournapeau wrote:
Hi David,
>
> I started a wiki page on the issues related to windows, 64 bits and
> python 2.6 (those issues are somewhat related at some level):
>
> http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport
Cool.
> If you want to help, you can try solving one proble
Ravi wrote:
>
>
> Given that commenting out the section above allows numpy to compile without
> any apparent side effects, is there any chance we could get "experimental"
> binaries of numpy 1.2.0 for python 2.6? I do understand that a negative
> answer
> is very likely and the reasons therefor
On Wednesday 08 October 2008 10:56:02 Hanni Ali wrote:
> We discussed errors you are encountering a few months ago, they are related
> to the compiler directives.
>
> > #ifndef HAVE_FREXPF
> > static float frexpf(float x, int * i)
> > {
> > return (float)frexp((double)(x), i);
> > }
> > #endif
Thanks Hanni! That did it. Numpy builds and installs by commenting
out:
#ifndef HAVE_FREXPF
static float frexpf(float x, int * i)
{
return (float)frexp((double)(x), i);
}
#endif
#ifndef HAVE_LDEXPF
static float ldexpf(float x, int i)
{
return (float)ldexp((double)(x), i);
}
Just to note, on the compilation issue, I encountered this a while ago with
numpy 1.1.1 and I think Python 2.6b2, again because we wanted to skip Python
2.5 in my organization, largely because it was an issue to get working on
64-bit. I couldn't find anywhere 7.1 was available.
We discussed errors
On 10/8/2008 10:29 AM Ravi apparently wrote:
> I sometimes wonder about the motivation for an
> unpaid volunteer to take on an utterly thankless job in which help is never
> forthcoming from users ...
> Thank for taking on this arduous task.
See, it is not entirely thankless. ;-)
I would like
Ravi wrote:
>
> The reasons above are why I don't try to do anything on Windows unless there
> is support from some external source, e.g., CMake taking care of build
> issues.
> The reasons above are also why I admire your heroic efforts at making Windows
> binaries available. But, then, I some
On Wednesday 08 October 2008 09:44:25 David Cournapeau wrote:
> For one, the manifest madness introduced with VS 2005 may be painful to
> handle, since it severly lacks any serious documentation. I am still
> unsure whether we will need to care at all, though.
>
> Another problem is that python hea
>Could you compress win-amd64-2.6\numpy\core\src\umathmodule.c -- it
>should be in the build directory -- and attach it if possible, or at
>least that part that seems to be a problem? Mind that the list has a
rather small size limit.
I think this is the pertinent section:
#ifndef HAVE_F
Ravi wrote:
> On Wednesday 08 October 2008 03:39:32 David Cournapeau wrote:
>
>> Note that 1.2.0 does not officially support python 2.6, specially on
>> windows. Because python 2.6 uses a new toolchain (VS 2008 by default
>> instead of 2003), it requires some non trivial changes.
>>
>
> How
Peter wrote:
>
> How about python 2.5 and numpy 1.2 instead? Python 2.6 makes some
> important changes to python 2.5 (in preparation for Python 3.0), so
> you may find several other packages will take a couple of months to
> work 100% with python 2.6 - so check this out if you do plan to use
> mor
On Wed, Oct 8, 2008 at 2:41 PM, Ravi <[EMAIL PROTECTED]> wrote:
> The majority of my colleagues work on Windows and are very resistant to
> toolset changes. Hence, from my perspective, whenever a new project starts, it
> is very important to start with the latest version of any software packages
>
Paul Lucek wrote:
>
> I get the following errors in umathmodule.c.src:
>
>
>
> D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe
> /c /nolog
>
> o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
> -Inumpy\cor
>
> e\include -Ibuild\src.win-amd64-2.6\numpy\co
On Tue, Oct 7, 2008 at 11:42 AM, Paul Lucek <[EMAIL PROTECTED]> wrote:
> I get the following errors in umathmodule.c.src:
>
>
>
> D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c
> /nolog
>
> o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
> -Inumpy\c
I get the following errors in umathmodule.c.src:
D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe
/c /nolog
o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
-Inumpy\cor
e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy
-Inumpy\core\src -I
22 matches
Mail list logo
