Although of likely little consequence for traditional pc/servers,
the inexact model I prefer is that typically adopted/approximated
by floating-point DSP's, which by their nature have no use for NaN's;
and instead tend to literally treat all encoded values as literal
values, thereby +-Inf and +-0.0 values merely represent maximum and
minimum represented magnitudes; thereby all calculations map inclusively
(regardless of the imprecision which may be silently introduced by
saturated intermediate calculations, without attempting generate and
propagate sticky NaN's or Inf's values through calculations, as doing
so only tends to result in catastrophic failure of an algorithm, as
opposed to the arguably a more graceful failure resulting from precision
being lost more incrementally due to intermediate saturated over/underflows.

Where if an exact non-signed 0 were also present and distinct from
+-0.0, I'd tend to prefer that only 0 multiplied by any value other than
it's reciprocal is 0, where 0 multiplied by it's reciprocal (an exact
non-signed infinity) is 1. Thereby:

 (* +0.0 [-Inf -> -1.0 ->  0  -> +0.0 -> +Inf])

      => [-1.0 -> -0.0 ->  0  -> +0.0 -> +1.0]

 (/ +0.0 [-1.0 -> -0.0 ->  0  -> +0.0 -> +1.0])

      => [-0.0 -> -1.0 -> 1/0 -> +1.0 -> +0.0]

 (* +Inf [-1.0 -> -0.0 ->  0  -> +0.0 -> +1.0])

      => [-Inf -> -1.0 ->  0  -> +1.0 -> +Inf]

 (/ +Inf [-Inf -> -1.0 ->  0  -> +1.0 -> +Inf])

      => [-1.0 -> -0.0 -> 1/0 -> +0.0 -> +1.0]

And finally:

 (* 0 1/0) :: (/ 0 0) => 1

(but unfortunately neither 0 nor 1/0 representations are supported by
IEEE-754, but may be relatively easily within a scheme implementation)

> From: Marcin 'Qrczak' Kowalczyk <xxxxxx@knm.org.pl>
>> Paul Schlie <xxxxxx@comcast.net> writes:
>> - as the propagation of a NaN beyond the source of the ambiguity only
>>   tends to further obfuscates the context of the problem, it typically
>>   inhibits a problem's diagnosis, and/or alternative most-likely-useful
>>   value/behavior substitution (as NaN's themselves are not useful within
>>   a context which requires/expects a definitive value, which is typically
>>   the case/expectation).
>
> When the programmer wants to be alerted as soon as an invalid
> operation is performed, he will turn on this exception. Let him
> decide. Please don't take away the useful choice of allowing NaNs
> to propagate and examine later which elements could be computed.
>
> <http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF>:
>
> | NaNs were not invented out of whole cloth. Konrad Zuse tried similar
> | ideas in the late 1930s; Seymour Cray built "Indefinites" into the
> | CDC 6600 in 1963; then DEC put "Reserved Operands" into their PDP-11
> | and VAX. But nobody used them because they trap when touched. NaNs
> | do not trap (unless they are "Signaling" SNaNs, which exist mainly
> | for political reasons and are rarely used); NaNs propagate through
> | most computations. Consequently they do get used.
>
> --
>    __("<         Marcin Kowalczyk
>    \__/       xxxxxx@knm.org.pl
>     ^^     http://qrnik.knm.org.pl/~qrczak/
>