Thomas Bushnell BSG <xxxxxx@becket.net> writes:

> It is an explanation of why your appeal to tradition is ill-founded;
> the tradition actually points the opposite way.

There is no tradition in not providing a read syntax for "error
objects".

Aubrey Jaffer said:

| I think that an implementation should be allowed to signal an
| error under some conditions where an error object is encountered.
| Mandating readable written representations for error objects
| prevents an implementation from signaling such errors.

There is no reason to signal an error when NaN is read. Having a
universally agreed syntax for both printing and reading NaNs is good
for portability.

There are reasons to signal an error when it would be produced (IEEE
specifies this in the form of an INVALID exception) and perhaps when
it's used in arithmetic (IEEE provides signalling NaNs in addition to
quiet NaNs, although most languages support only quiet NaNs), but not
when it's read and by default not when it's printed.

William Kahan has written in 1997
<http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF>
(emphasis mine):

| Twenty years ago anarchy threatened floating-point arithmetic.
| Over a dozen commercially significant arithmetics boasted diverse
| wordsizes, precisions, rounding procedures and over/underflow
| behaviors, and more were in the works. "Portable" software intended
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| to reconcile that numerical diversity had become unbearably costly
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| to develop.
  ^^^^^^^^^^
|
| Thirteen years ago, when IEEE 754 became official, major
| microprocessor manufacturers had already adopted it despite the
| challenge it posed to implementors. With unprecedented altruism,
| hardware designers had risen to its challenge in the belief that
| they would ease and encourage a vast burgeoning of numerical
| software. They did succeed to a considerable extent. Anyway,
| rounding anomalies that preoccupied all of us in the 1970s afflict
| only CRAY X-MPs--J90s now."
[...]
| 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.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| Perhaps NaNs are widely misunderstood because they are not needed
| for mathematical analysis, whose sequencing is entirely logical;
| they are needed only for computation, with temporal sequencing that
| can be hard to revise, harder to reverse. NaNs must conform to
                                            ^^^^^^^^^^^^^^^^^^^^
| mathematically consistent rules that were deduced, not invented
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| arbitrarily, in 1977 during the design of the Intel 8087 that
  ^^^^^^^^^^^
| preceded IEEE 754.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/