Hi Clive,
> 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 timekeeping :-)
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 checks.
> 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).
Rob Received on 2006-06-23Z07:33:30