gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: [Maxima] float to bfloat


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: [Maxima] float to bfloat
Date: 30 Jan 2004 13:07:40 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks for your feedback!

"Stavros Macrakis" <address@hidden> writes:

> > My understanding is that the Common Lisp spec is silent on an 
> > implementation's treatment of Nan and Inf.  If so, and we are 
> > implicitly free to implement them in a useful way, I'd be 
> > happy to do so for maxima's benefit.  Paul, can we define 
> > NaN, and Inf as symbols with floating point constant values, 
> > and 1/0, -1/0, and 0/0 as analogous rationals?  What would be 
> > useful rules regarding expressions involving these symbols, 
> > beyond NaN - NaN = NaN et. al. mentioned above? 
> 
> Existing Lisp code may expect 1/0 and 1/0.0 to give errors, not to
> silently return values.  It may explicitly catch those errors to do the
> right thing, or it may allow them to be propagated, signalling that its
> result is not valid.  Current code also silently returns float-infinity
> for (expt 9.9 9999), though 9.9e9999 gives a floating overflow error.
> 
> I don't think it's necessary to have constants NaN, Inf, etc.  User code
> can easily enough define such constants, e.g.
> 
>   (defconstant double-floating-infinity (expt 9.9d0 9999))
>   (defconstant double-floating-nan (sin double-floating-infinity))
> 
> After all, Common Lisp doesn't have standard constants for pi, sqrt(2),
> etc., does it?  I am not sure what you mean by 'rules regarding
> expressions' -- the machine's IEEE float implementation takes care of
> all that.  With the above definitions, you have:
> 
>   (= DFnan DFnan) => nil
>   (> Dfinf 0) => t
>   (/ 1 inf) => 0.0
> 
> though you also have
> 
>   (/ 1.0 0.0) => Zero divisor error
> 
> which I don't think you can turn off in GCL 2.5.0.
> 
> To fully integrate NaN/Inf/... into GCL, it would be nice to have
> standard input/output formats and make sure that all floating primitives
> do something useful with them.  I believe that integer-encode-float
> works with NaN/Inf, giving an unambiguous return value.  Constructing a
> NaN cannot of course be done in the usual way of constructing a float,
> namely (* sign mantissa (expt 2.0 exponent)).
> 

OK, so maybe the only useful change might be allowing such items to
print from this perspective.  BTW, are the following what you would
expect?

(integer-decode-float (expt 9.9d0 9999))

4503599627370496
972
1

>(integer-decode-float (sin (expt 9.9d0 9999)))

6755399441055744
972
-1

>

Take care,


> _______________________________________________
> Maxima mailing list
> address@hidden
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]