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.
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/