[Numpy-discussion] Hello and my first patch

[Albert Strasheim]

Hello all

Some comments from a Windows user's perspective.

On Thu, 05 Oct 2006, Travis Oliphant wrote:

> John Hunter wrote:
> 
> >>>>>>"Robert" == Robert Kern <robert.kern at gmail.com> writes:
> >
> >    Robert> IMO, I'd rather see this and similar functions go into
> >    Robert> scipy. New functions that apply semantics to arrays (in
> >    Robert> this case, treating them as time series), I think should
> >    Robert> go into scipy. New functions that treat arrays simply as
> >    Robert> arrays and are generally useful can probably go into
> >    Robert> numpy.
> >
> >I prefer Perry's longstanding suggestion: things that do not add to
> >distribution complexity should go into numpy.  If it compiles as
> >easily as numpy itself, it should go into numpy where sensible.  
> 
> I don't think this is as feasible as it sounds at first.  Some people 
> complain that NumPy is too big already.  

I agree here. Focus NumPy on doing array library things.

> SciPy is very easy to install on Windows (there is a binary available).  
> The only major platform that still gives some trouble is Intel Mac (due 
> to the fortran compiler situation).   But, all you need is one person 
> who can build it and distribute a binary.

So far, I've been shying away from SciPy, because, if I encounter a 
problem, I have no easy way of building from SVN on Windows. I don't 
think I'm the only one: few Windows users have a proper Fortran 
compiler. Sure, there's MinGW, but that breaks all my other tools, most 
notably the Visual Studio debugger and other useful things like 
profilers (e.g. IBM Rational Quantify).

That being said, Enthought's nightly builds obviate the need of most 
Windows users to build from source. (Enthought rocks.)

Two feature requests at this point, which would make
NumPy/SciPy/Matplotlib dead easy to use on Windows, even if you're 
trying to stay close to trunk:

1. Please consider setting up a buildbot(*) that builds and runs the 
tests on every checkin. I've set up a buildbot for NumPy on my own 
machine; it takes a matter of minutes. Probably they already have 
something like this in place.

(*) http://buildbot.sourceforge.net/

2. Please consider doing separate builds per CPU with ATLAS 3.7.11, 
Intel MKL and ACML. By all means, make a generic build available that 
runs everywhere. This will require some reading of the MKL license 
agreement, but I think Enthought should be able to distribute Windows 
builds based on MKL without problems. Why go to this trouble? MATLAB 
R2006b uses Intel MKL on my CPU, and it is much faster than NumPy with 
ATLAS 3.6.0. Core Duo users also have the option of enabling OpenMP, to  
spread calculations to multiple cores.

> I think a better long-term solution is to understand how to package 
> things better by working with people at Enthought so that when you 
> advertise to the ex-Matlab user you point him to a "super-package" that 
> installs a bunch of other small packages.  This is a more maintainable 
> solution as long as we set standards for
>
> 1) documentation
> 2) tests
> 3) some kind of problem-domain hierarchy

Agreed. If Enthought is willing to provide the resources, Enthon could 
be the perfect solution to many of the issues that we currently 
encounter to get decent builds on Windows.

> The idea of just lumping more an more things into NumPy itself is not a 
> good idea.  What most users want is something that installs easily (like 
> Enthon).   How it is packaged is not as important.  What developers need 
> is a sane multi-namespace system that can be maintained separately if 
> needed.
> 
> I think we decided a while ago, that the package approach should contain 
> indicators as to whether or not a fortran compiler was needed to build 
> the system so that dependency on those things could be eliminated if 
> needed. 
> 
> Do we want to pull scipy apart  into two components:  one that needs 
> Fortran to build and another that doesn't? 

Maybe. Maybe not. On Linux this doesn't make much difference to me if I 
check out 3 projects or 10 -- builds are easy. On Windows, getting the 
support libraries, build tools and configuration right is much harder. 
Hard enough, that I don't think anybody wants to do it regularly.
 
> Perhaps that is the best way to move forward along with the work on a 
> "pylab" super-package.

Yes, please.

Regards,

Albert