This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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 <qrczak@xxxxxxxxxx> >> Paul Schlie <schlie@xxxxxxxxxxx> 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 > \__/ qrczak@xxxxxxxxxx > ^^ http://qrnik.knm.org.pl/~qrczak/ >