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

*To*: clisp-list <clisp-list@ma2s2.mathematik.uni-karlsruhe.de>*Subject*: Re: CLTL compatible type contagion?*From*: haible@ilog.ilog.fr (Bruno Haible)*Date*: Mon, 7 Aug 95 22:28:15 +0200*In-reply-to*: <199508071844.OAA25120@screamer.rtp.ericsson.se>*References*: <199508071844.OAA25120@screamer.rtp.ericsson.se>,<199508071856.OAA25165@screamer.rtp.ericsson.se>,<199508071911.PAA25228@screamer.rtp.ericsson.se>

Raymond Toy writes: > I agree, it is nice, but I wish it could remind me a bit more > loudly. :-) Silently making all (following) results a single-float > makes it very difficult to find out where I made the original > mistake. :-) Not so difficult: you just have to look at the number of decimal places of your intermediate results. It would be more difficult to find out (or even notice) if you got double-floats with the 8 trailing decimal places filled with nearly random digits -- which is what ANSI CL suggests. > However, I have discovered the "errant" part of my program. I lose > precision because I had something like > > (sqrt 22/7) > > and clisp returned a float value. I guess the result would depend on > whether 22/7 has infinite precision/accuracy in which case the answer > should be a long-float (?) or whether 22/7 has accuracy of +/- 1/14 in > which case the answer should be short-float or less. The assumption > that 22/7 is a single-float is a bit hazy. Agreed. This is a second flaw in CLtL, this time in the description of the FLOAT function. 22/7, as a rational number, has infinite precision, so the result should be a long-float of the longest available float format. Since CLISP can deal with long-floats of more than 100000 decimal places, this is not very practical. For this purpose, CLISP provides a variable LISP:*DEFAULT-FLOAT-FORMAT*. Set it to DOUBLE-FLOAT, and (sqrt 22/7) will return a float of this type. > But what about this example? > > 1.000001 +/- 1e-8 > - 1.000000 +/- 1e-8 > =================== > 0.000001 +/- 2e-8 > > What should the type of the result be? These phenomena (extinction and the growth of the interval length) are considered to be inevitable with the usual IEEE floating point arithmetic. > The current scheme seems like a half-attempt at interval arithmetic. It is. > Either go all the way or don't go at all. One should go all the way. Follow-up to the comp.arch.arithmetic newsgroup. Bruno Haible email: <haible@ilog.fr> Software Engineer phone: +33-1-49083585

**References**:**Re: CLTL compatible type contagion?***From:*Raymond Toy <toy@rtp.ericsson.se>

**Re: CLTL compatible type contagion?***From:*Raymond Toy <toy@rtp.ericsson.se>

**Re: CLTL compatible type contagion?***From:*Raymond Toy <toy@rtp.ericsson.se>

- Prev by Date:
**Re: CLTL compatible type contagion?** - Next by Date:
**fence matching with editor** - Previous by thread:
**Re: CLTL compatible type contagion?** - Next by thread:
**fence matching with editor** - Index(es):