Python advocacy in scientific computation

[Brian Blais]

sturlamolden wrote:
> 
> Typically a scientist need to:
> 
> 1. do a lot of experiments
> 
> 2. analyse the data from experiments
> 
> 3. run a simulation now and then
> 

unless you are a theorist!  in that case, I would order this list backwards.


> 
> 1. Time is money. Time is the only thing that a scientist cannot afford
> to lose. Licensing fees for Matlab is not an issue. If we can spend
> $1,000,000 on specialised equipment we can pay whatever Mathworks or
> Lahey charges as well. However, time spent programming are an issue.
> (As are time time spend learning a new language.)
> 

Another person stated that they don't have infinite funds, as implied here.  I would
add that, in addition to one's own research, professors must also teach and advise.
I find it very helpful to be able to say to a student, "go download this, and here is
the code I wrote for the work I do".  The price is often an impediment for getting 
students into research.  Often there are site licenses, but they don't work off campus.


> 2. We don't need fancy GUIs. GUI coding is a waste of time we don't
> have. We don't care if Python have fancy GUI frameworks or not.
> 

again, for sharing ideas, GUIs are *necessary*.  If you work with people who do less 
programming than you, then you need to make an interface to your code that they can 
understand.  it doesn't have to be fancy, just functional.

> 3. We do need fancy data plotting and graphing. We do need fancy
> plotting and graphing that are easy to use - as in Matlab or S-PLUS.
> 

here, I've found python to be good, but not great.  matplotlib (pylab) is a really 
great thing, but is not as straightforward as plotting in Matlab.  Either, you have a 
window which locks the process until you close it, or you do interactive mode, but 
the window results disappear if any other window is put on top (like your shell), and 
has to be manually redrawn.  This makes it far less convenient to deal with in 
interactive mode.

> 4. Anything that has to do with website development or enterprise class
> production quality control are crap that we don't care about.
> 

I think it can be pitched as an alternative to shell-scripts, which is a nice economy 
of concepts: the language you use for your scientific work, you can also use for your 
OS work, and your tinkering.


> 7. "My simulation is running to slowly" is the number ONE complaint.
> Speed of excecution is an issue, regardless of what computer science
> folks try to tell you. That is why we spend disproportionate amount of
> time learning to vectorize Matlab code.
> 

here, I would plug Pyrex like crazy.  to me the Python/Pyrex combination is the 
biggest selling point for me to convert my scientific matlab code to Python. 
Learning a new API is a drag, and I've found that SWIG is not particularly intuitive 
(although convenient, if you have a lot of libraries already written).  Pyrex seems 
to get the best of all possible worlds: seamless use of python objects, and the 
ability to do C-loops for speed, with no API.  Making extensions this way is a real joy.


> Now please go ahead and tell me how Python can help me become a better
> scientist. And try to steer clear of the computer science buzzwords
> that don't mean anyting to me.
> 


I have been using Matlab for nearly 10 years.  My claim to no-fame is the neural 
network simulator Plasticity (http://web.bryant.edu/~bblais/plasticity) which has 
taken me years to write.  I have some complaints about Matlab, but it has been a 
useful tool.  Some of my complaints are as follows:

1) Cost.  I find that the marketing model for Matlab is annoying.  They 
nickle-and-dime you, with the base package (educational pricing) at $500 per 
machine/operating system/user and then between $200-$500 *per* "toolbox", which adds 
up really quick.   I can't even buy 1 license for a dual boot, to have Matlab run on 
a Linux partition and a Windows partition.

The cost impacts my use of Matlab in the classroom, and with research students.

2) License Manager.  The license manager for Matlab is the most inconvenient program 
I have ever dealt with.  It is incredibly sensitive to the license file, and it 
nearly impossible to debug.  This has made Matlab one of the hardest programs to 
install, for me.  The issue that impacts my productivity is the following: the 
license key is tied to the network card, on eth0.  Thus, if I upgrade my laptop, I 
need to contact Mathworks for an updated license key.  Also, occasionally, my 
operating system decides to name my wireless card eth0, and my wired card eth1. 
Nothing else is affected by this, but then I can't run Matlab!

3) Upgrade Version Hell.  *Every* time Matlab has upgraded, my program has broken. 
Usually something small, but still it is a real pain in the butt.  Also, I have to 
pay full price for the upgrade, or pay some fee continuously whether there is an 
upgrade or not.

I have only been using Python for about 2 months, so I can't speak to some issues, 
but what does Python offer me?

1) Free (as in free beer).  I've elaborated on this above.

2) Free (as in free speech).  I like the fact that I am not burdened by having my 
projects tied to something proprietary.

3) Distribution ease.  With py2exe, I can distribute on Windows systems which have no 
python installed.  That's a real plus!

4) Clean programming environment.  For teaching, it is nice to use a language which 
is so readable.

5) A huge number of built-in, or available, packages for nearly everything.

6) The ability to write portions of code in an optimized, as-fast-as-C, manner.

7) Relatively easy GUI frameworks

I'm sure there are other things, but that's the way I am thinking right now.


-- 
-----------------

             bblais at bryant.edu
             http://web.bryant.edu/~bblais