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: Sun, 23 Oct 2005 22:01:37 +0200 | From: =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <jensaxel@xxxxxxxxxxxx> | | Aubrey Jaffer wrote: | > | From: Thomas Bushnell BSG <tb@xxxxxxxxxx> | > | Date: Sun, 23 Oct 2005 12:39:43 -0700 | > | | > | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: | > | | > | > When different NaNs are returned depending on the circumstances | > | > creating them, I would like my implementation to display them | > | > like this: | > | > | > | > #<not-a-number expt> | > | | > | Sure, that seems fine. We could mandate that as the readable written | > | representation! | > | > It should *not* be a readable representation. That serves only to | > mask mathematical errors in saved datasets. As Bakul Shah wrote: | > "... IEEE754 says NaN is the result of an *invalid* operation, when an | > operation's operands lie outside its domain." | | Say I want to write my own mathematical function and need to return | NaN? E.g. | | (if <check-arguments> | <calculate-result> | #<not-a-number> | | is, to me, more readable than | | (if <check-arguments> | <calculate-result> | (/ 0.0 0.0)) That is a good point. Of course you would want the written representation to match the literal form so it works for program-writing programs. Argggh! In my experience writing lots of mathematical code, the trick is not generating NaNs, it is preventing them. Searching through my 70000 line Scheme codebase, I find no literal NaNs or infinities. For example, this code for EXPT generates NaNs when z1 is infinite. No tests or NaN literals are required: (exp (* (if (zero? z1) (real-part z2) z2) (log z1))) So I would prefer the (/ 0. 0.) option because I think it will arise rarely, if ever.