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.
| Date: Mon, 24 Oct 2005 15:53:55 -0500 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | | Aubrey Jaffer wrote: | > Are you suggesting a single NaN or multiple distinct NaNs? | > | > To support existing IEEE-754 hardware, R6RS must not mandate | > multiple distinct NaNs. But specifying a singular NaN prevents | > implementations from fully supporting IEEE-754 in the future. | | All hardware should recognize all NaNs. Therefore, allowing NaNs | to be generated with aribitrary bit patterns is not a problem. | However, different hardware need not generate the same NaNs for | identical operands. Having a universal read/write representation for arbitrary bit patterms prevents including information like the procedure causing the NaN in its printed representation. | However, I still think we need a read syntax. Suppose program A | calculates a value and writes it to a file and program B reads the | value from the file and uses it. Is is not useful for program A to | be able to communicate to program B that it got a NaN? To evaluate this scenario, we must compare it with the alternatives. In mission critical software, signaling an error instead of returning NaNs is unacceptable. Even if the error is caught, the computation is curtailed, requiring higher levels of exception awareness which are difficult to plan and test. If program A writes out its state, it would be useful to see that NaNs were computed. It gives operators a chance to capture the use case which provoked the error. If the program state is very valuable, then it can be repaired manually. But if program B reads its initial state from the file, its reading of NaNs puts errors into its state which can propagate and corrupt it. This is not an entirely hypothetical scenario. My database-backed HTTP servers write out their (Scheme) databases after changes; and read them in on reboot. | This would suggest we need a write syntax and a read syntax for | NaNs. I disagree.