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: > 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 \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/