> 2008/7/18 Tim Jenness <[log in to unmask]>:
> > I've just had a quick look at the inter dependencies of the kaplibs sub
> > libraries in preparation for breaking them out into their own libraries.
> >
> > AIF - no kaplibs dependencies
AIF is historical. Some of it is almost PAR. Some supplement FIO ADAM.
Some could be replaced by PSX for workspace in KAPPA.
> > On the assumption that KPG is higher up in the hierarchy than FTS and so is
> > *allowed* to call FTS then that means that the 2 routines used by FTS need
> > another home (although the RNANx routines in FTS1 are clearly out of place -
> > nothing to do with fits headers and all to do with replacement of NaN and
> > Inf with VAL__BADx so should arguably be in primdat somewhere)
Could we make these generic too. BTW I still have the original code
before it became easier to do the tests and revised by Tim Ash.
Some of this is history, but the IEEE 754 translations were needed for
the FITS floating-point data when this was introduced. FTS was not
merely FITS headers. They were the FITS-related routines used by the
FITS applications in KAPPA that long predated FITS2NDF. In another
reply you say the likes of FITSDIN is deprecated, which is close,
however, they do support some older not-quite-FITS that FITS2NDF does
not. Hence I wanted to retain them.
> > SGDIG - number of significant digits (primdat?)
Move it to FTS. It's to do with deciding the data type to be associated
with a floating-point value in a header.
> > SSAZx - scale an axis (BZERO/BSCALE)
This is widely used, alI guess we have to clone that functionality in
FTS. It's only a few lines of code.
> Options could include:
>
> 2) Include a copy of KPG1_SSAZx in FTS, renamed to FTS_SSAZx (cough)
Therefore I vote Option 2.
Malcolm
|