Is numpy v1.1 going to come out in egg format? I ask because I only see the superpack installers on the sourceforge page, and we have users who we are delivering to via egg - requires. thanks, Peter 2008/5/23 <numpy-discussion-request@scipy.org>:
Send Numpy-discussion mailing list submissions to numpy-discussion@scipy.org
To subscribe or unsubscribe via the World Wide Web, visit http://projects.scipy.org/mailman/listinfo/numpy-discussion or, via email, send a message with subject or body 'help' to numpy-discussion-request@scipy.org
You can reach the person managing the list at numpy-discussion-owner@scipy.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Numpy-discussion digest..."
Today's Topics:
1. Re: f2py errors: any help interpreting? (Mark Miller) 2. Re: f2py errors: any help interpreting? (Robert Kern) 3. Re: f2py errors: any help interpreting? (Mark Miller) 4. Re: f2py errors: any help interpreting? (Robert Kern) 5. Re: f2py errors: any help interpreting? (Mark Miller) 6. Re: f2py errors: any help interpreting? (Mark Miller)
----------------------------------------------------------------------
Message: 1 Date: Fri, 23 May 2008 14:48:47 -0700 From: "Mark Miller" <markperrymiller@gmail.com> Subject: Re: [Numpy-discussion] f2py errors: any help interpreting? To: "Discussion of Numerical Python" <numpy-discussion@scipy.org> Message-ID: <d1eaff10805231448i69fe8589v18062ef0f737f85@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"
Super...I'll give it a try. Or should I just wait for the numpy 1.1 release?
thanks,
-Mark
On Fri, May 23, 2008 at 2:45 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, May 23, 2008 at 4:00 PM, Mark Miller <mark.miller@usu.edu> wrote:
File "C:\Python25\lib\site-packages\numpy\f2py\rules.py", line 1222, in buildmodule for l in '\n\n'.join(funcwrappers2)+'\n'.split('\n'): TypeError: cannot concatenate 'str' and 'list' objects
Any thoughts? Please let me know if more information is needed to troubleshoot.
This is a bug that was fixed in SVN r4335.
http://projects.scipy.org/scipy/numpy/changeset/4335
-- 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
I would also like to see a 64bit build for windows as well if possible. Hanni 2008/5/30 Peter Creasey <p.e.creasey.00@googlemail.com>:
2008/5/30 Peter Creasey <p.e.creasey.00@googlemail.com>:
Is numpy v1.1 going to come out in egg format?
Oops, I didn't mean to mail with an entire numpy digest in the body.
sorry, Peter _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- E-mail: hanni.ali@gmail.com Mobile: +44 (0) 7985580147 My Blog: http://ainkaboot.co.uk/blogs/hanni/ Website: http://ainkaboot.co.uk http://drqueue.org
On Fri, May 30, 2008 at 8:35 PM, Hanni Ali <hanni.ali@gmail.com> wrote:
I would also like to see a 64bit build for windows as well if possible.
Unfortunately, this is difficult: windows 64 is not commonly available (I don't have any access to it personally, for example), and mingw is not available yet for windows 64 either. David
Hi David,
Unfortunately, this is difficult: windows 64 is not commonly available (I don't have any access to it personally, for example), and mingw is not available yet for windows 64 either.
I had managed to compile and install 1.04 with vs 2005 64 bit with a bit of hacking, however it had failed one of the regression tests. I will try numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows? Cheers, Hanni
Hanni Ali wrote:
I had managed to compile and install 1.04 with vs 2005 64 bit with a bit of hacking,
I can't build official binaries with VS: I don't have VS. Also, there is the problem of building the fortran dependencies (BLAS/LAPACK). I don't know if it is even possible to build ATLAS on windows x64. Even assuming we only use netlib BLAS/LAPACK, I still need a fortran compiler (gfortran).
however it had failed one of the regression tests. I will try numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows?
You need to use the same VS as python: this means VS 2003 for official python 2.5 (you can build python yourself with VS 2005 or 2008, though, but for distribution, this is not useful). cheers, David
Hi David,
I can't build official binaries with VS: I don't have VS. Also, there is the problem of building the fortran dependencies (BLAS/LAPACK). I don't know if it is even possible to build ATLAS on windows x64. Even assuming we only use netlib BLAS/LAPACK, I still need a fortran compiler (gfortran).
Yes I had used the internal versions in the mean time, but I do want to try to use the intel fortran compiler in all likelyhood. Python 2.6 is compiled with vs 2008 is is important that numpy is also compiled with the same compiler or not. The fact that a fortran compiler is necessary makes me think no?
however it had failed one of the regression tests. I will try numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows?
It looks like I'm going to look at 2.6 now due to dependencies on pywin32 as well. Also is it important that BLAS/LAPACK are compiled with the same compiler as python or not? (Obviously just the C++ parts) Thanks, Hanni
Hanni Ali wrote:
Yes I had used the internal versions in the mean time, but I do want to try to use the intel fortran compiler in all likelyhood.
Yes, people can try to build as they want, that's the beauty of open source :) But for official distribution, I don't want to depend on non free software (outside windows, obviously). I need a process to build numpy in a reproducible and in a hassle way (well, as much as possible, at least).
Python 2.6 is compiled with vs 2008 is is important that numpy is also compiled with the same compiler or not. The fact that a fortran compiler is necessary makes me think no?
This has nothing to do with fortran per se, but with the fact that MS keeps breaking the standard C runtime. Hopefully, with python 3, this may not be an issue anymore (python on windows won't use the standard C API, but windows API instead, because MS guarantees ABI in this case, at least that's what I understood). The fortran compiler has to be the same to build everything, but python does not use any fortran, so you can choose whatever you want as long as you use it for everything (BLAS, LAPACK and numpy).
It looks like I'm going to look at 2.6 now due to dependencies on pywin32 as well.
Also is it important that BLAS/LAPACK are compiled with the same compiler as python or not?
BLAS/LAPACK is built with fortran, and python with C compiler, so no :) What may be important is the C++ compiler to build (more exactly to link) python if you build python by yourself, but I don't know how this works on windows. I just build softwares for windows, I don't use it. cheers, David
Excellenm, thanks for clearing all that up. How about numpy with 2.6, any issues? Hanni 2008/6/2 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Hanni Ali wrote:
Yes I had used the internal versions in the mean time, but I do want to try to use the intel fortran compiler in all likelyhood.
Yes, people can try to build as they want, that's the beauty of open source :) But for official distribution, I don't want to depend on non free software (outside windows, obviously). I need a process to build numpy in a reproducible and in a hassle way (well, as much as possible, at least).
Python 2.6 is compiled with vs 2008 is is important that numpy is also compiled with the same compiler or not. The fact that a fortran compiler is necessary makes me think no?
This has nothing to do with fortran per se, but with the fact that MS keeps breaking the standard C runtime. Hopefully, with python 3, this may not be an issue anymore (python on windows won't use the standard C API, but windows API instead, because MS guarantees ABI in this case, at least that's what I understood).
The fortran compiler has to be the same to build everything, but python does not use any fortran, so you can choose whatever you want as long as you use it for everything (BLAS, LAPACK and numpy).
It looks like I'm going to look at 2.6 now due to dependencies on pywin32 as well.
Also is it important that BLAS/LAPACK are compiled with the same compiler as python or not?
BLAS/LAPACK is built with fortran, and python with C compiler, so no :) What may be important is the C++ compiler to build (more exactly to link) python if you build python by yourself, but I don't know how this works on windows. I just build softwares for windows, I don't use it.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi David, I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA libs to minimise complexity. Although I have hacked it such that I can compile and all but one of the regression tests passed: ====================================================================== ERROR: Tests reading from a text file. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py", line 363 , in test_fromtextfile fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s") ValueError: Invalid format string ---------------------------------------------------------------------- Ran 1267 tests in 1.141s FAILED (errors=1) <unittest._TextTestResult run=1267 errors=1 failures=0> This appears to be a problem with the strftime function in test_mrecords.py The error seems to be created by the millisecond formatting argument %s, removing this caused the test to pass. So I think it's all ok really, however in order to get numpy to compile I have commented out a small part which was causing compilation to fail: numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type' numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type' This relates to this section of code: #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); } #endif The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be recognised by msvc 9 would you agree with that assessment? And a redefinition of a function present in the stdc library is occurring. What do you think? By just commenting out this piece of code numpy compiles and appears to function. Hanni 2008/6/2 Hanni Ali <hanni.ali@gmail.com>:
Excellenm, thanks for clearing all that up.
How about numpy with 2.6, any issues?
Hanni
2008/6/2 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Hanni Ali wrote:
Yes I had used the internal versions in the mean time, but I do want to try to use the intel fortran compiler in all likelyhood.
Yes, people can try to build as they want, that's the beauty of open source :) But for official distribution, I don't want to depend on non free software (outside windows, obviously). I need a process to build numpy in a reproducible and in a hassle way (well, as much as possible, at least).
Python 2.6 is compiled with vs 2008 is is important that numpy is also compiled with the same compiler or not. The fact that a fortran compiler is necessary makes me think no?
This has nothing to do with fortran per se, but with the fact that MS keeps breaking the standard C runtime. Hopefully, with python 3, this may not be an issue anymore (python on windows won't use the standard C API, but windows API instead, because MS guarantees ABI in this case, at least that's what I understood).
The fortran compiler has to be the same to build everything, but python does not use any fortran, so you can choose whatever you want as long as you use it for everything (BLAS, LAPACK and numpy).
It looks like I'm going to look at 2.6 now due to dependencies on pywin32 as well.
Also is it important that BLAS/LAPACK are compiled with the same compiler as python or not?
BLAS/LAPACK is built with fortran, and python with C compiler, so no :) What may be important is the C++ compiler to build (more exactly to link) python if you build python by yourself, but I don't know how this works on windows. I just build softwares for windows, I don't use it.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jun 3, 2008 at 3:21 AM, Hanni Ali <hanni.ali@gmail.com> wrote:
Hi David,
I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA libs to minimise complexity.
Although I have hacked it such that I can compile and all but one of the regression tests passed:
====================================================================== ERROR: Tests reading from a text file. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py", line 363 , in test_fromtextfile fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s") ValueError: Invalid format string ---------------------------------------------------------------------- Ran 1267 tests in 1.141s FAILED (errors=1) <unittest._TextTestResult run=1267 errors=1 failures=0>
This appears to be a problem with the strftime function in test_mrecords.py
The error seems to be created by the millisecond formatting argument %s, removing this caused the test to pass.
Well, this should be using tempfile anyways.
So I think it's all ok really, however in order to get numpy to compile I have commented out a small part which was causing compilation to fail:
numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type' numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
This relates to this section of code:
#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); } #endif
The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be recognised by msvc 9 would you agree with that assessment?
And a redefinition of a function present in the stdc library is occurring.
What do you think? By just commenting out this piece of code numpy compiles and appears to function.
The presence of these functions should have been detected by the configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have been #define'd if we had detected them correctly. It is possible that our configuration process for this does not work correctly with VS 2008. From a clean checkout, can you please do the build again and copy-and-paste everything printed to the terminal? -- 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
Robert Kern wrote:
The presence of these functions should have been detected by the configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have been #define'd if we had detected them correctly. It is possible that our configuration process for this does not work correctly with VS 2008. From a clean checkout, can you please do the build again and copy-and-paste everything printed to the terminal?
As an aside, I don't understand how the configuration is supposed to work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of functions ? I don't understand why for example testing for expf is supposed to be enough to guarantee the presence of the whole float functions (HAVE_FLOAT_FUNCS). What is the rationale for that ? Why not testing for every function we are using ? David
On Tue, Jun 3, 2008 at 9:49 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Robert Kern wrote:
The presence of these functions should have been detected by the configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have been #define'd if we had detected them correctly. It is possible that our configuration process for this does not work correctly with VS 2008. From a clean checkout, can you please do the build again and copy-and-paste everything printed to the terminal?
As an aside, I don't understand how the configuration is supposed to work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of functions ? I don't understand why for example testing for expf is supposed to be enough to guarantee the presence of the whole float functions (HAVE_FLOAT_FUNCS). What is the rationale for that ?
Someone thought that it was a sufficient condition. If it is not, then it should be fixed.
Why not testing for every function we are using ?
There are a lot of them. Feel free to add any additional tests you think are necessary, and we'll see how painful it is at build-time. -- 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
Robert Kern wrote:
There are a lot of them. Feel free to add any additional tests you think are necessary, and we'll see how painful it is at build-time.
What would be acceptable ? I quickly tested on my macbook, on mac os X: it takes ~ 2 seconds / 25 functions tests. If speed really is a problem, than we can first test them as a group, and then one by one for the platforms where it does not work (something like AC_CHECK_FUNCS_ONCE, if you are familiar with autotools) ? It should not be too complicated to add this to distutils, and I believe it would make the configuration more robust, cheers, David
On Tue, Jun 3, 2008 at 8:49 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Robert Kern wrote:
The presence of these functions should have been detected by the configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have been #define'd if we had detected them correctly. It is possible that our configuration process for this does not work correctly with VS 2008. From a clean checkout, can you please do the build again and copy-and-paste everything printed to the terminal?
As an aside, I don't understand how the configuration is supposed to work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of functions ? I don't understand why for example testing for expf is supposed to be enough to guarantee the presence of the whole float functions (HAVE_FLOAT_FUNCS). What is the rationale for that ? Why not testing for every function we are using ?
It probably just grew to fix problems as they arose. It should be possible to test for every function and fall back to the double versions that are more reliably present. It would be nicer if all compilers tried to conform to recent standards, i.e., be less than 9 years out of date, but that is a bit much to ask for. Chuck
Charles R Harris wrote:
It probably just grew to fix problems as they arose. It should be possible to test for every function and fall back to the double versions that are more reliably present. It would be nicer if all compilers tried to conform to recent standards, i.e., be less than 9 years out of date, but that is a bit much to ask for.
Most compilers are not compatible (none of them supports C99 at 100 %; the better question is which subset is powerfull and implemented thouroughly). I had some surprising problems with numscons and mingw, and obviously MS compilers/runtime (each version has a different configuration for the part of the code we are talking about). cheers, David
Hi Robert, Attached is the complete output, below is what I believe is the relevant area of interest: compiling C sources creating build\temp.win-amd64-2.6\Release\build creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6 creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src -Inumpy\core\include -Ibuild\src.win-amd64-2.6\numpy\core -Inumpy\core\src -Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC -IC:\Python26\include -IC:\Python26\PC /Tcbuild\src.win-amd64-2.6\numpy\core\src\umathmodule.c /Fobuild\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj umathmodule.c numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type' numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type' numpy\core\src\ufuncobject.c(1645) : warning C4244: '=' : conversion from 'npy_intp' to 'int', possible loss of data numpy\core\src\ufuncobject.c(2346) : warning C4244: '=' : conversion from 'npy_intp' to 'int', possible loss of data What I find odd is that the instruction:
#ifndef HAVE_FREXPF
should not produce the error (at least that's what I would have thought) i.e. if it isn't recognised the compiler should simply be using the alternate definition of the frexpf function defined, although I suspect it is a little less efficient than the float one from the libs. Hanni 2008/6/3 Robert Kern <robert.kern@gmail.com>:
Hi David,
I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA libs to minimise complexity.
Although I have hacked it such that I can compile and all but one of the regression tests passed:
====================================================================== ERROR: Tests reading from a text file. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py",
On Tue, Jun 3, 2008 at 3:21 AM, Hanni Ali <hanni.ali@gmail.com> wrote: line
363 , in test_fromtextfile fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s") ValueError: Invalid format string ---------------------------------------------------------------------- Ran 1267 tests in 1.141s FAILED (errors=1) <unittest._TextTestResult run=1267 errors=1 failures=0>
This appears to be a problem with the strftime function in test_mrecords.py
The error seems to be created by the millisecond formatting argument %s, removing this caused the test to pass.
Well, this should be using tempfile anyways.
So I think it's all ok really, however in order to get numpy to compile I have commented out a small part which was causing compilation to fail:
numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type' numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
This relates to this section of code:
#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); } #endif
The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be recognised by msvc 9 would you agree with that assessment?
And a redefinition of a function present in the stdc library is occurring.
What do you think? By just commenting out this piece of code numpy compiles and appears to function.
The presence of these functions should have been detected by the configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have been #define'd if we had detected them correctly. It is possible that our configuration process for this does not work correctly with VS 2008. From a clean checkout, can you please do the build again and copy-and-paste everything printed to the terminal?
-- 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sat, May 31, 2008 at 12:01:10PM +0900, David Cournapeau wrote:
On Fri, May 30, 2008 at 8:35 PM, Hanni Ali <hanni.ali@gmail.com> wrote:
I would also like to see a 64bit build for windows as well if possible.
Unfortunately, this is difficult: windows 64 is not commonly available (I don't have any access to it personally, for example), and mingw is not available yet for windows 64 either.
I was just wondering, could we ask Microsoft for some help here. A build bot, or a Windows 64 license... They are helping porting the SAGE project to windows, so they do have interest in getting open source scientific software working on windows. My 2 cents, Gaël
Gael Varoquaux wrote:
I was just wondering, could we ask Microsoft for some help here. A build bot, or a Windows 64 license... They are helping porting the SAGE project to windows, so they do have interest in getting open source scientific software working on windows.
Windows 64 is actually the easiest problem: you can find free trial license for Windows server 2008 on MS website. The main problem is the compiler and BLAS/LAPACK: mingw cannot target 64 bits yet (there is a mingw-w64 project, but after some digging, I found out that it was legally dubious, hence not integrated yet in the 'real' mingw project). Now, you could think about using MS compiler, but I don't like the idea very much, and there is the problem of blas/lapack. cygwin, already slow, is dog slow on windows 64 (because it runs in 32 bits, I guess ?), and is needed to build atlas (blas and lapack too, but it is at least theoretically possible to build them without makefiles; atlas build system is so complicated that it makes autotools feel extremely enjoyable). cheers, David
I have used the trail of Visual Studio 2008 (on full Server 2003) it copmiles and runs well if you comment out the lines meantioned earlier on in this thread. I am planning to spend some time with the intel fortran compiler to try to compile blas/lapack in the next few weeks. It is part of my current project, so I will report back, Intel are usually very friendly to open source and if that means you offer intel optimised binaries they should hopefully be willing. Hanni (P.S. I sent an output from the compile in an earlier thread, but I think it was filtered I will re-post it and try to compress it a bit) 2008/6/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Gael Varoquaux wrote:
I was just wondering, could we ask Microsoft for some help here. A build bot, or a Windows 64 license... They are helping porting the SAGE project to windows, so they do have interest in getting open source scientific software working on windows.
Windows 64 is actually the easiest problem: you can find free trial license for Windows server 2008 on MS website.
The main problem is the compiler and BLAS/LAPACK: mingw cannot target 64 bits yet (there is a mingw-w64 project, but after some digging, I found out that it was legally dubious, hence not integrated yet in the 'real' mingw project). Now, you could think about using MS compiler, but I don't like the idea very much, and there is the problem of blas/lapack. cygwin, already slow, is dog slow on windows 64 (because it runs in 32 bits, I guess ?), and is needed to build atlas (blas and lapack too, but it is at least theoretically possible to build them without makefiles; atlas build system is so complicated that it makes autotools feel extremely enjoyable).
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (7)
-
Charles R Harris -
David Cournapeau -
David Cournapeau -
Gael Varoquaux -
Hanni Ali -
Peter Creasey -
Robert Kern