[SciPy-dev] Re: [AstroPy] Python version of IDL Astron library
Travis E. Oliphant
oliphant at ee.byu.edu
Mon Sep 13 19:20:28 CDT 2004
Since Tom invited me into the discussion, I will comment, despite the
fact that I am not an astronomer.
> Hi folks-
> Sorry to have missed all of the interesting discussion on this; I was
> at the HEAD meeting (on a panel on astrostatistics software, among
> other things---lots of folks are interested in Python, by the way).
> Joe's summary of the main issues was very good. I agree on many
> points; here are some possible disagreements.
>>1. Numarray for all new code, and to teach to new users.
The reality is that Numarray is not ready as a drop-in replacement for
Numeric but people keep introducing it to new users as if it were ready.
This is a real problem in the community right now.
These issues have been discussed before and are on the scipy.org wiki
that Eric has started. Basically the issues preventing a drop-in
replacement are 1) small arrays are too slow, 2) no backward-compatible
ufunc C-API --- nothing like the compatibility API for arrays exists for
ufuncs. 3) migrating legacy code is way too time consuming and effort
filled for almost no gain.
While not optimal the current best solution is to make Numarray more
aware of Numeric arrays and vice versa, so that unnecessary memory
copying is not happening.
>>2. Matplotlib for all plotting. Try it. You'll like it!
Chaco is nearly there. In some ways I feel bad that John Hunter didn't
use his energy to making easy plots using Chaco/ Tk instead of
developing yet another infrastructure. It is true that matplotlib got
to a functional state more quickly, but chaco has a much more sturdy
foundation for development, I think.
The Enable library that Enthought has put together allows amazing
possibilities and improved portability. Their motives are completely
pure, though their time is limited. It would be nice if Enthought
published the location of their chaco SVN server so that users could see
the current code and not the legacy stuff in SciPy. I think the reason
they haven't is more of a logistic issue (not being ready to support
inquiries) and perhaps separating it from other code bases. But, if
Eric is reading this, I would suggest to him, that not publishing and
promoting the SVN site creates more problems and discourages potential
users in just the way Tom is expressing.
> Do either of these packages (matplotlib, Chaco) allow one to interact
> with plots in a way that lets Python easily know where on a plot the
> user is clicking? I.e., is there the basis for making "interactive"
> plots, not merely in the sense of panning and zooming, but in actually
> manipulating points on the plots as controls (maybe "dynamic" would be
> a better adjective)? I have in mind something like SysQuake
I believe chaco/enable makes this kind of thing very possible.
> g77 is free and trivial to install on OS X. In my experience
> Fortran on linux and the Mac isn't problematical. Is this a
> Windows problem? Are there really many astronomers using Windows for
> scientific calculation?
g77 also works under Windows. This should not be a problem. SciPy is
compiled under Windows using g77 constantly.
>>Documentation is a strong suit of IDL's and we need to be as good. I
>>am not aware of a standard doc header for Python.
> What little there is that is standard is outlined by Guido:
>>The source language of docs is another issue. It has to be open and
>>functional on all platforms. It has to handle simple markup and
>>inline figures. It has to produce PDF and HTML. MSWord is out.
>>Research Structured Text or LaTeX are my votes. Some like LyX and
>>TeXmacs. We'll see what the community wants.
> I'd love to see a format that allows including equations somehow, or
> some "web"-like framework (referring to Knuth's WEB, not the world-wide
> one) that allows one to jointly maintain fairly extensive technical
> documentation with the code.
I say, use LaTeX format in equations in doc strings if necessary and use
LyX as a format for documentation. The file format is structured text
that with the LyX editor becomes very easy to manipulate.
> I believe Bill Press and Saul Teukolsky wrote software (or had it
> written) for maintaining Numerical Recipes code within LaTeX for
> their book. Perhaps we can find out about what they did to see
> if it might be adaptable to our purposes.
> Regarding coordination with SciPy, it may be worth pointing out
> that the astrostat project I have funded by AISR supports Travis
> Oliphant for a month a year to support the project. He's offered
> to host our Inference package at SciPy.org. Perhaps I can persuade
> him to make that just a part of a larger set of packages, and get
> his help behind hosting our effort at SciPy.org (in this last year of
I hope that the AstroPy coordinates with SciPy. A lot of build issues
have been worked out in SciPy. SciPy has been explicitly designed to
work with subpackages. I see no reason that much of what astropy wants
to have available can't be a sub-package of SciPy. If there are
reasons, then we need to fix them on the SciPy end, or the stated
purpose of SciPy is not being fulfilled.
Now, I can also see the blossoming of very special-purpose packages, but
the line between special-purpose and general is changing all the time.
However, if there are general-purpose algorithms that apply beyond
astronomy, they really should be in SciPy and not in a different
location. SciPy is supposed to be a community effort. There is room
for many more developers in the SciPy world.
More information about the Scipy-dev