[AstroPy] Co-ordinating Python astronomy libraries?

[Scott Ransom]

Hi Perry et al,

The Fortran version of SLALIB that I wrapped was GPLd.  You can get the 
code here (SLALIB + wrappers and tests):

http://www.cv.nrao.edu/~sransom/pyslalib-1.0.tar.gz

Scott

On Thursday, July 08, 2010 10:13:38 am Perry Greenfield wrote:
> A  SLALIB wrapper would be great (and justifiably part of an
> astronomy toolset).  Of course, the problem is with SLALIB itself
> since it doesn't have an open source license. (That's something that
> other would have to obtain and install separately). That's the big
> drawback.
> 
> Perry
> 
> On Jul 6, 2010, at 12:39 PM, Anne Archibald wrote:
> > Hi,
> > 
> > I use a couple of python astronomy libraries; the python bindings
> > to the pulsar search library PRESTO, and the python bindings to
> > the FORTRAN library SLALIB. Both were written by Scott Ransom;
> > obviously I can't speak for his motivations in writing them.
> > 
> > I think I follow a fairly common pattern, though: the libraries I
> > use are fairly thin wrappers of existing compiled code, and in one
> > case the code is very domain-specific. So combining them somehow
> > with other python libraries would involve either linking together
> > a huge mass of different compiled libraries with overlapping
> > functionality, or modifying the underlying libraries. Either one
> > would be a tremendous amount of work.
> > 
> > That said, I use SLALIB for a simple coordinate conversion (in fact
> > I use it to replicate exactly another coordinate conversion done
> > in compiled code, so this is kind of theoretical), so in principle
> > if there were a generic python astronomy library that covered this
> > (I didn't find one) I might have used it instead. The PRESTO code,
> > not so much; it includes some extremely specific pulsar searching
> > code that can't reasonably be included in existing python
> > libraries.
> > 
> > What might be nice would be a "standard" list of data types for
> > common objects, so that at least one could pass objects from one
> > library to another. RA and Dec objects, perhaps, or time objects.
> > Of course time objects would be a massive headache if you wanted
> > them to be generically usable, since they'd need to be good to the
> > nanosecond over a span of millenia (so doubles won't cut it),
> > support UTC/TDB/TAI/etc. as well as MJD/sidereal/GMT/local time
> > representations... Nevertheless, compiled code (and thin wrappers)
> > tend to just take doubles and rely on the user to keep track of
> > what they mean, while a more pythonic and less error-prone
> > approach would use python's type system to catch many errors.
> > 
> > Anne
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989