[SciPy-user] Why is SciPy better than Matlab or IDL? ; ) (Vincent van Beveren)

Craig Finch oanjao at yahoo.com
Tue Jul 7 11:42:02 EDT 2009


As a PhD candidate working in computational nanoscience, I have found Python to be extremely helpful.  I had extensive experience using Matlab before starting my research.  I will tell you about the incident that prompted me to switch to Python.  I wrote a GUI for a data analysis program using Matlab.  It worked well for about six months, and then I decided to make some changes in the GUI.  I went back to look at my code and I had no idea what was going on.  I spent a few hours trying to figure out the mess and decided it would just be faster to do it in Python, even though I was much less familiar with that language.  Matlab is fundamentally a procedural language--it's fine for writing simple one-page programs, but it quickly becomes unmanageable when writing larger, more complex programs.  I find that my Python code is much easier to read and organize.

There is a Python interface (through Numpy and Scipy) to all of the classic numerical routines found on Netlib.org.  The iPython interactive shell, combined with Matplotlib, provide interactive computing and high-quality plotting.  I have not run into any situation in my research where I regretted using Python because some feature was not available, nor have I hit any critical bugs.

I am using Python to write a Brownian dynamics simulator for interface chemistry.  While the interpreted parts of a Python program run more slowly than C or Fortran, most of the time-consuming numerical operations are performed compiled C or Fortran libraries, so the speed difference is not as much as you might think.  Further, there are numerous ways to accelerate Python programs by integrating compiled code.  Check out scipy.weave.inline, which lets you write C code write in the middle of a Python program to accelerate the slow parts.  Tools like boost.python and f2py make it easy for you to write C and Fortran libraries for the slowest portions of your code.  My development cycle is simple: quickly write everything in Python, profile the code to find what runs slowly, and write those parts in C or Fortran (if necessary).  

Overall, I'd recommend Python to another scientist because it's the fastest way to go from ideas to computational results.

   Craig



Message: 3
Date: Tue, 7 Jul 2009 16:03:07 +0200
From: Vincent van Beveren <V.vanBeveren at rijnhuizen.nl>
Subject: [SciPy-user] Why is SciPy better than Matlab or IDL? ;)
To: "'scipy-user at scipy.org'" <scipy-user at scipy.org>
Message-ID: <2926F4BC94217A43A2D21792DE8818931C5B245B29 at ex1.rijnh.nl>
Content-Type: text/plain; charset="us-ascii"

Hello everyone,

I'm an engineer at Rijnhuizen, which is a research institute for plasma physics. We use Python to drive one of our main research projects, however, in the scientific circles in this institute Python (and SciPy) are largely unknown. Time to change this, I think :). However, since I am an engineer and not a scientist I my viewpoint on Python and SciPy are more of an engineering perspective, like its Open Source, Free, modern language, functional programming, etc... I'm not entirely sure these are compelling arguments for a scientist to start working with Python (or atleast not on it self). So I was wondering, if I was to promote Python in the scientific community here at Rijnhuizen. So I have a few questions:

-          In what aspects does SciPy excel, compared to say IDL or matlab?
-          In what ways allows it a scientist to be more effective?
-          How usable is SciPy for Plasma physics, molucular dynamics and nanolayer Surface and Interface Physics (the 3 main areas at Rijnhuizen)?
-          How stable is it compared to other packages. (bugs, computation)?

Any comments and insights are welcome!

Regards,
Vincent

PS. Posted in scipy-dev by accident.
___
Ing. V. van Beveren
Software Engineer, FOM Rijnhuizen
E: V.vanBeveren at rijnhuizen.nl<mailto:V.vanBeveren at rijnhuizen.nl>



      



More information about the SciPy-User mailing list