[AstroPy] Python version of IDL Astron library

[Travis E. Oliphant]

<x-flowed>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.
> 
> 
>>UNDERLYING PACKAGES
>>
>>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
> (http://www.calerga.com/).
> 

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.

> 
>>DOCS
>>
>>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:
> 
> http://www.python.org/doc/essays/styleguide.html
> 
> 
>>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.
> 
> 
>>COORDINATION
> 
> 
> 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 
> funding!).
> 

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.

-Travis Oliphant



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