[AstroPy] Python version of IDL Astron library
perry at stsci.edu
Mon Sep 13 19:31:41 CDT 2004
On Sep 13, 2004, at 6:04 PM, Tom Loredo wrote:
> 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.
>> UNDERLYING PACKAGES
>> 1. Numarray for all new code, and to teach to new users.
> There was recently discussion of Numeric vs. numarray on the SciPy
> list, and my impression from it was that SciPy will *not* be switching
> to numarray anytime soon (i.e., within say a year) due to issues of
> small array performance and some different conventions. Is this an
> accurate impression? I think it is a big pain in the neck that all the
> useful computing is done with a great package (SciPy) that uses
> Numeric, but that astronomical i/o is with a great package (pyfits)
> that uses numarray . I think anything that can be done to make Numeric
> a package of the past would be good; having two packages for array
> calculations is certainly an obstacle for new users.
I addressed this at scipy. The point I made was that it was clear that
was going to have to be coexistance for at least a while. What we would
to do is make it possible for 3rd party packages to support both
numarray so the problem you mention goes away.
>> 2. Matplotlib for all plotting. Try it. You'll like it!
> I'm just getting into it, and though I like it overall, I think
> its quality and completeness have been exaggerated from a Mac OS X
> user perspective. I bounce back and forth every day between linux
> and OS X, and it definitely has some warts on OS X. But it is
> probably "inheriting" these from Tk and/or wx. If there is ever
> an Aqua version of gtk, that might solve things, but my searching
> along those lines has not been encouraging.
It would be nice to know what they are (at least from the Tk
we support that backend).
> The Chaco situation has me feeling a little miffed. If I recall
> correctly, it was built with NASA funding. But it was incomplete at
> the end of the funding period. Since then Enthought has gone on
> improving it, and it sounds like neat things have been done, but it has
> either been inaccessible or not easily accessible. It gives the
> impression that NASA funded a small business startup that has left
> little of lasting value to astronomers in return for the funding (in so
> far as Chaco by itself is concerned). This reflects rather poorly on
> Enthought and provides a negative example to NASA of what has come of
> funding Python development.
I think this summary gives a misleading impression of what happened.
NASA didn't directly decide to fund Enthought to do this, STScI did
as part of its work on Python infrastructure (and it was my idea to
do so, so it's really my responsibility, not NASA's). While I certainly
regret that it didn't result in a successful graphics package for our
purposes (though it did result in a useful spinoff, Traits) and it was
not an insignificant amount of money, it was an order of magnitude less
than is spent on a typical NASA AISR grant (many of which also don't
result in much useful in the way of results; I hope yours is different
And the amount of money Enthought got was never critical to their
success (they had already much more income from other sources).
If you are going to be miffed, I'm the proper target.
Enthought is still using chaco internally. I'd say that it really is
not in any state useful for most projects, mainly because it is changing
so rapidly and there is little documentation to describe the current
(and even if it did exist, it would likely become rapidly obsolete).
Furthermore, the current development is only being done on MS Windows
using WxPython. Using it with other GUI's or platforms will likely take
substantial work. I'm guessing it's still at least 6 months to a year
from being useful for others. We gave up on it because it was becoming
that it was too ambitious and complex for our most immediate needs.
> 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
Yes. In fact this is what makes Chaco more complex. It has a lot of
in machinery to handle interaction including selecting and manipulating
graphics elements (you could drag a plotted curve to a new location if
set it up properly. Matplotlib does have means to obtain a clicked x,y
position, but the user has to handle what is done as a result of that
> 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
Sounds like you are talking about chaco-like features. But you'll have
to wait. And it will be more complex to use (one of the reasons we
the value of such capabilities is that after all the interactive
makes, there is no easy means of applying the same changes to your next
whereas with a plot script there is an easy means to do so. It isn't as
but I'll argue it is generally more useful for most astronomers. Adding
capabilities to an interactive system isn't impossible, but it isn't
in the Chaco plan, and such things are generally tricky to implement
than obvious to use and apply. But I may be misreading what you are
for. I'm hoping that matplotlib doesn't try to do too much in this
least for a while.
>> I was
>> told at the conference that Python, C, and C++ are all easy to get
>> working, but that FORTRAN is problematic.
> 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?
Engineering, certainly. Many of scipy downloads are for windows. It may
be for astronomy, but scipy has to worry about a bigger community. It's
not just windows that is the problem. One has to devise a distribution
that works easily for all platforms. Just because you have few problems
Mac OS building certain applications doesn't mean that there aren't
in building the same applications on other platforms in a way that
require twiddling with make files and such. With fortran, the
conventions change from platform to platform, then there are the linking
issues. Things are much more standard with C.
>> There are strong benefits to writing in a compiled language, the main
>> one being portability to later interactive languages.
> I think folks should follow the typical Python development path:
> Develop in Python, with just the time-intensive parts rewritten in
> C, etc., as necessary. I think the emphasis should be on a good
> interface and getting the algorithm available quickly. Developing
> as much as possible in Python I think will make things available
> more quickly.
I'll agree with you here (so long as existing code in C or Fortran
can't do the job; it makes little sense to rewrite well tested libraries
so long as they are suitably portable).
> In the last few years Python very quickly got to the "75-80% level"
> as a scientific computing tool. But the pace has really dragged
> (to my perception) in the last year or so for closing the gap
> (and I'm partly to blame in regard to a stats package I'm writing).
> That last 20% or so is crucial; though one encounters the missing
> pieces only a fraction of the time, a *lot* of time gets wasted
> working around them, and it discourages use. So I think this
> community project Joe et al. has started is a great idea, but let's
> focus on getting stuff done quickly and well, and worry about
> performance (in the sense of writing lots in C/C++/Fortran) later.
Well, for us the drag was with plotting. Without a plotting, it wasn't
going to go anywhere. I think things are looking much brighter now.
AstroPy mailing list - astropy at stsci.edu
More information about the AstroPy