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.
From: Aubrey Jaffer <agj@xxxxxxxxxxxx> Subject: Re: reading NaNs Date: Tue, 25 Oct 2005 18:45:29 -0400 (EDT) > 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. It depends. Program B may decide to discard the part of the result of program A which includes NaN and continue to operate, or replacing NaNs with special values to indicate anormality. There are cases that program A cannot decide by itself whether its result including NaN is useful by the downstream or not. There are cases that manual repairment of NaNs are too expensive. I had such experiences in the production environment. So I would need to read NaNs safely. However, if having read-syntax for NaN hurts integrity of the numeric system as a standard, I can live with srfi-10 (e.g. #,(nan)). --shiro