NaN

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