Comments on: IDL vs. Python

By: Kelle

Kelle — Thu, 28 Jan 2010 14:23:14 +0000

I’m closing the comments. Please continue this conversation on the wiki page instead: http://www.astrobetter.com/wiki/tiki-index.php?page=idl_vs_python

By: Jessica

Jessica — Thu, 28 Jan 2010 04:48:38 +0000

@Josh

Now we have a version of the Pros/Cons list on the wiki. The wiki version is meant to be updated. I modified to reflect your comment about Mayavi2.

http://www.astrobetter.com/wiki/tiki-index.php?page=idl_vs_python

By: python .gt. IDL

python .gt. IDL — Tue, 26 Jan 2010 05:21:24 +0000

python + numpy/scipy + matplotlib + pyfits + pymc is far and away a better choice for new astronomers than IDL. It is true that python still doesn't natively do all of the niceties that IDL does for astronomers (by the way, the Greenfield document is quite old in python years), but just because IDL does something should not imply that IDL does it well. Interpolation is an easy example. Support for sparse matrices and a thorough wrapping of linalg packages (e.g. lapack), robust and flexible spline interpolation, automagic MCMC, a huge assortment of filtering options, pickle, shelve, matplotlib (which makes much nicer plots than IDL), clean syntax, simple OO interfacing, many optimization routines (MPFIT has been ported, but that's really just levenberg-marquardt, which has been in scipy for a long time -- check out openopt for a great deal of optimizers!), huge community, and it is free. And this last point really is important because it attracts even more (perhaps non-astronomer) users to help build the codebase. Python is worth it just for pymc -- perhaps this will finally motivate astronomers to treat their data and models properly!

By: Joshua Bloom

Joshua Bloom — Thu, 24 Dec 2009 18:42:04 +0000

The pro/con list seems a bit outdated. For instance, there is now surface plots in matplotlib. Check out the surface demo. Your readers might be interested in seeing a bunch of matplotlib figures. Rendering figures is starting to get as powerful in python as it is in IDL. For truly cool 3d stuff, check out Mayavi2, which is part of the Enthought Distribution.

By: Tom

Tom — Wed, 25 Nov 2009 04:31:00 +0000

Marshall already answered most of your questions, but just wanted to add a few things. First, about the ‘core’ package. The short answer is that if you don't mind not having the absolute latest and greatest versions of every python module, you can use something like the Enthought Python Distribution which includes many pre-installed libraries (including numpy, scipy, matplotlib, and the MySQL-python Marshall was mentioning). This provides a very complete set of (non-astronomy) python modules. Most astronomy packages are fairly simple and will install on top of EPD without much problem. EPD is available for Mac/Linux/Windows if I am not mistaken, and is free for Academics. As to the question about C compilers, quite a few python modules include C code (e.g. numpy) that is compiled on the fly when the package is installed, using whatever C compilers are available on the host machine. Some packages also include Fortran code that is compiler using whatever Fortran compiler is available. Finally, it is actually possible to write C code inside python code using the scipy.weave package, and this code is compiled at runtime. Array library: NumPy and Scipy have tons of array manipulation routines. Polygon clipping: I think SymPy has a good geometry package to do that kind of thing Map projection: Not sure if you mean WCS (pywcs) or something like basemap. On a side note, I see the diversity of Python modules as a good thing, even if it means spending a little more time installing things, because it allows anyone to contribute small easily installable modules to do a specific thing well. I do think Astronomy modules in general need more coordination, but the fact that there are multiple FITS or WCS modules out there is good, as this drives competition and ultimately improves the quality of the packages. I hope this helps!

By: Marshall

Marshall — Wed, 25 Nov 2009 01:25:20 +0000

There is not yet any equivalent to “use NASA lib & MPFIT” for Python. A reasonably starting point would be “use Numpy+Scipy+Matplotlib”, but there is as yet no standardized set of astronomy specific packages equivalent to Goddard. It’s early, things are in flux and there are still multiple competing alternatives (for instance the several implementations of WCS). Which is in some ways good, and in other ways bad. Establishing a common set of starting packages for beginners is definitely an area which could use some improvement. (And the ease of install of packages varies wildly. Many are as simple as typing ‘easy_install packagename’ but others require wrestling with compilers. I still can’t get the MySQL interface to build properly on Snow Leopard for some reason.)

My impression is that the Matplotlib plotting framework is very solid and consistent. The ability to hit ’save’ and produce a PDF file that looks pretty much exactly like any given window is a huge plus. But I’ve not tried specifically to predict the size of display strings like you asked. And live resizable windows! It’s like a breath of fresh air.

Don’t get me wrong, I still spend more time in IDL than in Python right now, particularly given the three humongous applications I’m working on that I really don’t want to port. And there are some things each language feels more smooth at. But I consider myself a relative neophyte in Python in a lot of ways (maybe green belt level, hopefully on my way up to a black belt eventually to match my ones in taekwondo and IDL. and I’m trying to produce more new code there right now.

By: JDS

JDS — Tue, 24 Nov 2009 22:43:20 +0000

I wonder if those ex-IDLers now using Python (+ associated scientific computing packages, hereafter for convenience called “Iython”) can comment on the following:

- How easy is it for end users to install the various packages needed for a “core” Iython install, including plotting, data handling, widgets, etc., for Win/Linux/Mac? And a related question…

- A basic set of instructions for an end user of distributed IDL routines/packages might be “use IDL > X.X; NASA Lib, MPFIT on IDL search path,” with a very high chance the code will run out of the box if those minimal dependencies are satisfied. How short or long would the equivalent install instructions for an Iython package of comparable complexity be?

- Does Iython come with its own C compiler, so that you can distribute platform agnostic C code and have it auto-compiled? If not, what advantages does Python offer in plugging in C or other code, compared to, say, MAKE_DLM?

- Is there a preferred editor which understands the operator constructs in NumPy, etc.?

- Does Iython offer interfaces to array libraries, polygon clipping libraries, map projection libraries, etc.

- Does Iython’s plotting framework use a consistent set of fonts for display/vector output/hardcopy? Can you predict in advance the size (horizontal and vertical) of displayed strings for precise positioning?

Thanks.

By: Eli

Eli — Thu, 29 Oct 2009 23:13:02 +0000

WesTF and Adam are both onto something. I wrote a program earlier this year that replicates the IDL save/load capability. The program looks through all of your global environment variables in a Python session and selects the numpy arrays automatically when you choose to save. After seeing the comments on this topic and a push from several colleagues I’ll clean up the code and post it for download so others can use it.

By: WesTF

WesTF — Thu, 29 Oct 2009 22:22:28 +0000

If saving is really a concern to python users, they could always adopt the pickle library. It can do most of what idl save does, but is more specific.

By: Adam Ginsburg

Adam Ginsburg — Wed, 21 Oct 2009 13:54:33 +0000

Tom Robitaille and the AstroPython/APLpy group released IDLsave about two weeks ago. That should alleviate some of the concerns about saving, especially if they come up with a 'write' package to match.