Hi,
just to add my opinion on NaN in the IEEE standard. As far as I
remember, IEEE numbers work as follows:
1 bit sign
some bits base
some bits exponent
This allows you to do several things:
interpret the exp bits as a normal integer and get
- exp=below half: negative exponents
- exp=half: exponent=0
- exp=above half: positive exponents
- exp=all set: NaN, quite a few at that
For all of these the sign can be either positive or negative, leading
to pos/neg zero (quite a strange concept).
With the NaNs, you get quite a few possibilities, but notably:
- base=0 (NaN -- this is not a number, but an animal)
- base=max (pos/neg infinity, depending on sign)
Someone mentioned a representation for 0/0 and I might add that there
are four possibilities:(( 1.)*0.) / (( 1.)*0.)(( 1.)*0.) / ((-1.)*0.)((-1.)*0.) / (( 1.)*0.)((-1.)*0.) / ((-1.)*0.)
These (given commutativity, except that we're dealing with a finite
representation, but predictable in that it is actually possible to
factor out the sign) can be reduced to:( 1) * (0./0.)(-1) * (0./0.)
which amounts to pos/neg infinity of some sort.
Now my take on NULL vs NaN is that there should be a whole bunch of
NULL, just like there is a whole bunch of NaN. Just off the top of my
head, I could imagine "unknown", "unknowable", "out of range in
direction X". But, alas, the SQL standard doesn't provide for such
things (though the storage implementation would: but what would you do
with comparisons, conversions and displays?).
so long,
Oliver
