Empty TD element wording
seaman at noao.edu
Wed Jun 21 07:53:29 PDT 2006
> Since the set-theory basis of RDBMS actually becomes inconsistent
> in the face of even one type of null, there are many who think that
> they are all evil.
It's issues like this that bring computer science into conflict with
the various communities (not just astronomy) that use computers. If
the real world (or virtual, for that matter) reveals requirements for
special values such as null, it should be computer science that
adjusts to suit. (Seems to me I've had this discussion regarding
Or perhaps there is already some standard answer for how an RDBMS
should support missing or overflow data values?
> In practice, as Mark said astronomers have long managed with just
> one type of null in FITS files.
Poorly, I think - and only IEEE floating point. For image arrays,
for instance, the only coherent way to handle special valued pixels
is to carry around a separate mask marking those pixels. For a
table, this is equivalent to instantiating an arbitrary number of
flags attached to each row or even each field in each row. Maybe the
answer is just that you have to punt by preceding each per-pixel or
per-field mathematical operation with several boolean conditionality
> I think it would be more productive to work on a standard way of
> expressing the notion of upper (or lower) limits - something which
> is so far missing from most astronomical formats.
Seems like a separate issue - overlimit/underlimit versus NaN versus
no-data. Absence of evidence is not evidence of absence is not a
handling error (such as a "mathematical" exception - really a failure
of an algorithm or data representation in most cases).
More information about the votable