NaN's Paul Schlie (29 Oct 2005 15:50 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 16:39 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 18:22 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 19:14 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 22:49 UTC)
Error objects in general bear (29 Oct 2005 19:46 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (29 Oct 2005 20:22 UTC)
Re: Error objects in general bear (30 Oct 2005 05:57 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (30 Oct 2005 14:17 UTC)
Re: Error objects in general Alan Watson (29 Oct 2005 21:26 UTC)
Re: Error objects in general bear (30 Oct 2005 05:40 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 05:45 UTC)
Re: Error objects in general bear (30 Oct 2005 06:08 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 16:49 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 05:54 UTC)
Re: Error objects in general bear (30 Oct 2005 06:07 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 06:46 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 12:39 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 13:04 UTC)
Re: Error objects in general John.Cowan (30 Oct 2005 16:30 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 20:29 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 13:17 UTC)

Re: NaN's Marcin 'Qrczak' Kowalczyk 29 Oct 2005 16:39 UTC

Paul Schlie <xxxxxx@comcast.net> writes:

> Upon further thought, it's not clear that specifying a NaN
> error-object is necessary or desirable; as in all cases it would
> appear preferable to signal a recoverable exception,

IEEE-754 already specifies that (the "invalid" exception). But it's
important to be able to proceed without establishing an explicit
handler too, in which case NaN is returned.

Since the presence of invalid operations in inexact arithmetic depends
on rounding errors for unfortunate input, and not merely on bugs in
the program, it should not be fatal by default. It's hard to predict
at which stage it will happen before it happens, thus it's important
to be able to set it up such that it produces a value which behaves
like a number (doesn't cause further errors in numeric processing),
so it can be checked at convenient places instead of after each
operation.

> Where then default most-likely-useful numeral results may be
> specified if desired, or left implementation specific (whereby
> then an implementation may choose to explicitly represent a NaN
> error-object it so chooses, however not mandated to do so by the
> standard).

If it's not mandated, then I can't rely on that. It increases the
amount of unportable code relying on a useful feature which is present
everywhere in practice but not formally standard, and decreases the
usefulness of the standard.

> Where then, an error-object may be independently specified as a
> proposed srfi independently, where by then such an object (such as
> <void> for the sake of argument), may be returned in lieu of an
> otherwise valid object as a result of any calculation, numeral or
> otherwise, as may be desired in lieu of a recoverable exception
> handler returning an otherwise more useful value.

The point in NaN is that it passes through arithmetic without errors,
so checking for it can be postponed. It makes no sense to replace it
with something which is not a valid argument of arithmetic.

For operations which don't uniformly work on inexact numbers such
object is much less useful. For non-numbers the behavior is generally
predictable and bad arguments imply a bug in the program rather than
unfortunate data.

Why so many people want to "fix" aspects of IEEE which are not broken?

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