On Tue, Jul 6, 2010 at 2:46 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
First about the test output: in 0.8.0rc1 all printed warnings, the lapack_misaligned and the npyio errors are gone. The boost errors will be gone in the final release as well. So you have about 20 errors/failures left, mostly located in the sparse and odr modules. Unless you're a heavy user of those, no need to move to matlab. You could also decide to look into the errors instead of rewriting your code.
Thanks... I depend on the sparse module quite heavily which is why it's a problem. (my code that uses spsolve is giving incorrect results, although no errors). It's probably not as bad as I made out though - I'm sure I can do a fair bit with 32 bit Python, it's just more difficult to make it accessible to my colleagues (will have to install 32 bit MATLAB and they will have to pay attention to which one they are using).
I know Windows isn't very popular in the Scipy community, and I try to avoid using it when I can, but it seems Windows 7 is a lot better than previous versions. Also >4GB RAM is now more or less standard for numerical work so I think 64 bit windows really should be supported. In my group a large factor in the decision to use windows was remote desktop and terminal services... For non-command line users there is nothing equivalent that I know of. (There is NX for linux but only 2 users is free - with a small tweak to windows 7 it is possible to have full terminal server behaviour).
I wonder how enthought get around this problem with 64 bit EPD on windows?
So why not use EPD? Still many times cheaper than Matlab....
I would suggest that if I had any influence at all on purchasing decisions, but as a PhD student I don't. Also MATLAB license is paid for by central IT, whereas any extra software would have to come out of group grants. If I wasn't the only person using it there might be a case, but unless I can get it working on Windows I'll continue to be the only person using it! (bit of a chicken and egg). Cheers Robin