On Wed, 21 Jun 2006, Mark Taylor wrote:
> On Tue, 20 Jun 2006, Doug Tody wrote:
>> It would be good to make a distinction between a numerically indefinite
>> value (NaN for floating point) and no value (undefined, NIL, NULL,
>> etc.). I think what is being talked about here is an "undefined"
>> value, i.e., an element for which no value has been assigned. Even for
>> floating data, something other than NaN is needed to specify an
>> undefined value.
>
> I can see that this can be justified in theoretical terms, but I must
> admit I've never thought much about the distinction and any software
> I've written has got on fine by using NaN (or a magic integer value)
> to cover both undefined and numerically indefinite. FITS BINTABLE
> and IMAGE seem to have managed without the distinction as well.
> Are there really compelling scenarios for this requirement?
It really depends upon the application, and the semantics of what is using the stored data. It is common in RDBMS for example to recognize the case of a field which has not yet been assigned any value; an application which uses the DBMS may need to recognize this case and take special action, e.g., apply some default value. In astronomy we also see this with parameter sets for example, where a parameter which has not yet been assigned any value is quite different than one which has, for example null is a legal value for a string and is not the same as undefined/unset.
When I wrote this earlier I was thinking mainly of the RDBMS case. However, I agree that for data values, especially in arrays (as in the FITS examples), a single value is probably sufficient, and this is the main usage of VOTable/BINTABLE etc. In the case of data values this single value probably means indefinite/NaN. If only a single value is implemented, it is still a good idea to be clear about the distinction between undefined and indefinite and what is intended.