Re: CLTL compatible type contagion?

[haible@ilog.ilog.fr (Bruno Haible)]

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