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.
> Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> writes:
>> Paul Schlie <schlie@xxxxxxxxxxx> 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.
- agreed, and largely specific to IEEE-754 based implementations.
> 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.
- 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).
>> 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.
- which seems reasonable for IEEE-754 based inexact implementations, but
but not otherwise. (which seems to imply they're potential necessity
is implementation specific)
>> 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.
- as NaN's are arguably only proxies for non-well-specified context
sensitive values/behaviors, their silent propagation tends to only
further expand the context of the ambiguity they represent, therefore
arguably ideally should never be introduced, much less propagated,
to begin with. (in my opinion)
> 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.
- agreed, which is why I don't believe NaN is a reasonable default result
for any numerical calculation.
> Why so many people want to "fix" aspects of IEEE which are not broken?
- possibly because NaN's are largely a result of a committee who couldn't
agree on alternative more likely typically useful results, or an efficient
exception handling mechanism to enable them in a way which was compatible
with the then existing/pending commercial implementations and practices.
>
> --
> __("< Marcin Kowalczyk
> \__/ qrczak@xxxxxxxxxx
> ^^ http://qrnik.knm.org.pl/~qrczak/
>