[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLTL compatible type contagion?
Raymond Toy writes:
> I asked about this before, and the answer was no, clisp does not do
> type contagion as specified in CLTL2. The current behavior is to
> convert everything to the smallest floating-point type instead of the
> largest as most other languages typically do and as specified by CLTL.
> Some sensible reasons for this are given in impnotes.txt.
> However, I was doing some numerical prototyping with clisp and came
> across this very annoying problem with the current type contagion:
> (+ 1d50 1.0)
> does not return 1d50. Instead, it signals a floating-point overflow.
> I presume that clisp does the addition in double-float and then
> coerces the result to single-float, causing the overflow.
Yes. It would actually make sense to return 1d50 in that case since
1.0e0 is so much less in magnitude. But the problem remains for example
in the case
(+ 1d40 1e37)
Returning 1.001d40 for this would be wrong (IMO) since the two numbers,
considered as intervals, add up like this:
1d40 +/- 1e24
1e37 +/- 1e29
1.001d40 +/- 1e29
And if ANSI CL says that:
"Common Lisp functions assume that the accuracy of arguments to them
does not exceed their precision"
then of course the implementation shall do its best to guarantee that if
the arguments of the function `+' satisfy this assumption, then the
result of (+ 1d40 1e37) satisfies this assumption as well. If it can't,
I prefer to see an error.
My advice is: if you need numbers larger than 1e38 in your computations,
then use double floats or long floats for everything. And if you need
numbers larger than 1e600 then use long floats. Their exponent range
is virtually unlimited in CLISP.
Bruno Haible email: <firstname.lastname@example.org>
Software Engineer phone: +33-1-49083585