[fitsbits] Bintable proposals

[Don Wells]

Mark,

>>>>> "Mark" == Mark Calabretta <Mark.Calabretta at atnf.CSIRO.AU> writes:
    Mark> Your solutions are complicated, hardware-based workarounds
    Mark> to what is essentially a simple software problem.  We
    Mark> already have all the hardware needed *AND* a simple software
    Mark> solution - RPFITS, but the aim is to move away from that to
    Mark> something more portable.

Standard FITS is portable.  As I demonstrated in my earlier posting in
this thread, it is possible to write arbitrary standard FITS files at
high speed in a real-time context by using either disk or RAM
buffering.  The disk solution is particularly attractive, as the RT-OS
disk subsystem does most of the tricky mutual exclusion work for the
designer (e.g. management of the disk directory).  In fact, in the
case of the VLBA Correlator I did not regard the disk solution as a
'complicated' part of my overall real-time design problem. The coding
of it turned out to be easy, and it was robust.  Managing the locks
and multiple lightweight threads, and spawning new threads, is easy in
any POSIX-like RT environment (such as VxWorks).

    Mark> This raises another question: what should a general bintable
    Mark> reader do if it encounters an EOF before reading the number
    Mark> of rows specified by NAXIS2?  Hopefully not crash!  So
    Mark> should it adjust its own value of the number of rows to
    Mark> reflect what it found (if it matters)?  If so, could we
    Mark> instead set NAXIS2 to some huge value and rely on the EOF?

A design which can raise such questions is not robust and general.

The philosophy that headers should explicitly and unambiguously
declare the number of bits used by binary data objects was implicit in
the original Basic FITS Agreement of 1979.  This philosophy was
codified as part of the Generalized Extensions Agreement five years
later. This codification appears today in the NOST Definition of FITS
in Sections 5.4.1.2 and 7.1 and, in particular, as equation (5.2).

    Don Wells as quoted by Mark:
    >> .., a reader which applies a strict interpretation of the rules
    >> would declare a negative NAXIS2 dimensionality to be in
    >> violation of the explicit rule for NAXISn in Section 5.4.1.1 of
    >> the NOST Definition of FITS..

    Mark> ...and it can't be changed??

It appears to me that (probably) the rules for NAXIS2 could be changed
in the manner you desire without violating the backwards compatibility
rule stated in Section_9 of the NOST Definition of FITS. (This rule
was also a part of the Generalized Extensions Agreement of 1984, and
is often stated as 'once FITS, always FITS'.) 

However, the probable result of such a change would be potential
ambiguity about the number of rows in the array.  Perhaps a majority
of the FITS community would want to make this change in spite of the
ambiguity (I doubt it). My own present opinion is that I regard such
ambiguity as a 'bad thing' in an interchange and archival format, so I
will argue against this change.  I doubt that I could ever be
persuaded to change my opinion about this matter.

-Don
-- 
  Donald C. Wells      Scientist - GBT Project        dwells at nrao.edu
                    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-434-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA
       (DCW is often in Green Bank, West Virginia, at +1-304-456-2146)