On Sat, Jul 19, 2014 at 3:57 AM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> Hmmm, there's something to what you say there, but IEEE-754 NANs seem to
> have been designed to do quadruple (at least!) duty with multiple
> meanings, including:
>
> - Missing values ("I took a reading, but I can't read my handwriting").
>
> - Data known only qualitatively, not quantitatively (e.g. windspeed =
> "fearsome").
>
> - Inapplicable values, e.g. the average depth of the oceans on Mars.
>
> - The result of calculations which are mathematically indeterminate,
> such as 0/0.
>
> - The result of real-valued calculations which are invalid due to
> domain errors, such as sqrt(-1) or acos(2.5).
>
> - The result of calculations which are conceptually valid, but are
> unknown due to limitations of floats, e.g. you have two finite
> quantities which have both overflowed to INF, the difference
> between them ought to be finite, but there's no way to tell what
> it should be.
Huh, okay. I thought the definition of NaN was based on the fourth one
(mathematically indeterminate) and then it logically accepted the
subsequent two (sqrt(-1) IMO is better handled by either a complex
number or a thrown error, but NaN does make some sense there;
definitely inf-inf => nan is as logical as 0/0 => nan). The first two
seem to be better handled by SQL's NULL value (or non-value, or
something, or maybe not something); the third is a bit trickier.
Although "the average of no values" is logically calculated as 0/0
(ergo NaN makes sense there), I would say NaN isn't really right for a
truly inapplicable value - for instance, recording the mass of a
non-physical object. In an inventory system, it's probably simplest to
use 0.0 to mean "non-physical item", but it might be worth
distinguishing between "physical item with sufficiently low mass that
it underflows our measurements" (like a single sheet of paper when
you're working with postal scales) and "non-physical item with no
meaningful mass" (like credit card fees). In that case, I'm not sure
that NaN is really appropriate to the situation, but would defer to
IEE 754 on the subject.
Obviously it's possible to abuse anything to mean anything (I do
remember using nullable fields in DB2 to mean everything from "inherit
this value from parent" to "here be magic, code will work out the real
value on the fly"), but this is a question of intent and good design.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
