| 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.