[fitsbits] Extended Comment Period on 2 FITS Proposals

[Mark Calabretta]

On Tue 2004/11/02 17:39:17 CDT, Bob Garwood wrote
in a message to: William Pence <William.D.Pence at nasa.gov>
and copied to: FITSBITS <fitsbits at nrao.edu>

>I think it would be more useful in that case if the TDIM values for that 
>column could be expressed as a column itself instead of a keyword.  e.g. 
>if the variable column in question is column 05 then somewhere you'd 
>have another column with a TTYPE value of "TDIM05". 

I believe that the reference to "the length specified in the variable
length array descriptor" in the addendum means the (variable) length
parameter stored in the table for each row, not the maximum array length
encoded in the "P" TFORMn keyvalue.  So it is ok to write a TDIM column
that varies from row to row.  Perhaps the wording could say that
explicitly.

>Secondly, I think the above is useful even in the case where 
>variable-length arrays aren't used.  If you have nearly the same sized 
>arrays to store in a column, you could pad them all out to the same size 
>and store them without wasting too much space.  In that case, it would 
>be useful to mearly require that the number of elements implied by any 
>TDIM in the column be <= the element count for the column it refers to 
>and you'd have an associated column of TDIMs that would describe the 
>specific shape of each cell.

This does seem a useful way to store a kind of variable-length array
without having to resort to using a heap, though possibly wasting some
space.  What reason did the IAUFWG give for imposing this restriction?

Also, assuming that B.1 is accepted, perhaps we should be referring to
fixed-dimension and variable-dimension arrays.

Mark Calabretta
ATNF