[AstroPy] Python version of IDL Astron library

[Perry Greenfield]

<x-flowed>
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 
there
was going to have to be coexistance for at least a while. What we would 
like
to do is make it possible for 3rd party packages to support both 
Numeric and
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 
perspective,
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 
state
(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 
away
from being useful for others. We gave up on it because it was becoming 
clear
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 
built
in machinery to handle interaction including selecting and manipulating
graphics elements (you could drag a plotted curve to a new location if 
you
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 
click.

> 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
> (http://www.calerga.com/).
>
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 
discounted
the value of such capabilities is that after all the interactive 
changes one
makes, there is no easy means of applying the same changes to your next 
plot
whereas with a plot script there is an easy means to do so. It isn't as 
sexy,
but I'll argue it is generally more useful for most astronomers. Adding 
such
capabilities to an interactive system isn't impossible, but it isn't 
currently
in the Chaco plan, and such things are generally tricky to implement 
and less
than obvious to use and apply. But I may be misreading what you are 
asking
for. I'm hoping that matplotlib doesn't try to do too much in this 
area, at
least for a while.

>> PYTHON/C/C++/FORTRAN
>>
>> 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 
not
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 
system
that works easily for all platforms. Just because you have few problems 
on
Mac OS building certain applications doesn't mean that there aren't 
glitches
in building the same applications on other platforms in a way that 
doesn't
require twiddling with make files and such. With fortran, the 
interlanguage
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.

Perry

_________________________________________________
AstroPy mailing list     -      astropy at stsci.edu
http://www.astro.washington.edu/owen/AstroPy.html
</x-flowed>