Path: utzoo!attcan!uunet!ogicse!decwrl!shelby!neon!max
From: max@Neon.Stanford.EDU (Max Hailperin)
Newsgroups: comp.lang.lisp
Subject: Re: IEEE FP NaNs = everything else?
Message-ID: <1990Mar16.161849.18850@Neon.Stanford.EDU>
Date: 16 Mar 90 16:18:49 GMT
References: <1990Mar15.211150.19338@Neon.Stanford.EDU> <34725@news.Think.COM>
Organization: Computer Science Department, Stanford University
Lines: 29

In article <34725@news.Think.COM> barmar@nugodot.think.com.UUCP (Barry Margolin) writes:
>In article <1990Mar15.211150.19338@Neon.Stanford.EDU> max@Neon.Stanford.EDU (Max Hailperin) writes:
>>Has anyone explored the possibility of useing IEEE floating-point as a
>>general representation in a manifestly-typed language, with everything
>>other than flonums being NaNs (Not-A-Numbers)?
>
>The IEEE rule is that any arithmetic involving NaNs must result in a NaN.

That's for quite NaNs -- I had signalling NaNs in mind, in which case you could
take a trap and do whatever you felt like.

>But if fixnums are implemented as NaNs then this means that (+ 3.0 1) must
>evaluate to a NaN rather than 4.0, since this would be (+ 3.0 NaN).

See above.

>Perhaps, instead of using NaNs for all non-fixnums you should use NaNs for
                                            ^^^ I assume you meant flo
>all non-numbers (NaN *does* stand for Not a Number, so this makes sense).

If we just used the IEEE flonum representation for all numbers, even integers,
than that would sort of make sense [though there are serious problems], but
then we would still be using NaNs for all non-flonums, because non-numbers and
non-flonums would be one and the same.

>You could then use signalling NaNs, which would cause ordinary IEEE FP
>hardware to trap on things like (+ 3.0 'a).

As I said up front, why not use this for (+ 3.0 1) as well?