"Murray Peterson" <mwp_at_home.com.invalid> wrote in message
news:Xns914F91C154058farkle_at_24.71.223.45...
> "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in
> news:1004906388.28075.0.nnrp-14.9e984b29_at_news.demon.co.uk:
> > Presumably you don't try to store those
> > values in the database though. It would
> > be a modelling error to do so. The fact
> > that a hardware device has to report an
> > error condition through a special value
> > doesn't mean that a database used to
> > hold the data should do the same.
> Yes, we store them in the database, and doing so is not a modelling error.
> What we retrieve from the database must be guaranteed to be identical to
> what came in from the field -- even a single bit error can't be tolerated.
> If at any time the device sends a value (no matter how erroneous or
> unexpected), the database *must* be able to store that value, even if it
is
> unexpected from the original design. In other words, I may never expect
> the values 1.0e-100 and 1.0e+1000, but if they show up, then I must store
> them for later retrieval -- an error message is not an accepatble option.
> The fact that the devices use the extreme portions of the IEEE range for
> indicators is only part of the problem. ...
That's right, having unusual values in not necessarily an error. It is
not even necessarily an error to have infinities or NANs (not-a-numbers).
It is indeed a serious shortcoming if a database cannot faithfully
handle an IEEE floating point number.
Received on Mon Nov 05 2001 - 01:54:46 CST
