| Date: Sun, 23 Oct 2005 22:01:37 +0200 | From: =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <xxxxxx@soegaard.net> | | Aubrey Jaffer wrote: | > | From: Thomas Bushnell BSG <xxxxxx@becket.net> | > | Date: Sun, 23 Oct 2005 12:39:43 -0700 | > | | > | Aubrey Jaffer <xxxxxx@alum.mit.edu> 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.
