[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLTL compatible type contagion?
- To: clisp-list <firstname.lastname@example.org>
- Subject: Re: CLTL compatible type contagion?
- From: Raymond Toy <email@example.com>
- Date: Mon, 07 Aug 1995 14:43:28 -0400
- In-reply-to: (Your message of Mon, 07 Aug 1995 20:01:41 +0200.) <9508071711.AA05660@ilog.ilog.fr>
>>>>> "Bruno" == Bruno Haible <firstname.lastname@example.org> writes:
Bruno> Raymond Toy writes:
>> (+ 1d50 1.0)
>> does not return 1d50. Instead, it signals a floating-point
>> overflow. I presume that clisp does the addition in
[nice example of why clisp does it this way deleted]
Bruno> then of course the implementation shall do its best to
Bruno> guarantee that if the arguments of the function `+' satisfy
Bruno> this assumption, then the result of (+ 1d40 1e37) satisfies
Bruno> this assumption as well. If it can't, I prefer to see an
By your example, (+ 1d40 1e37) does not satisfy the assumption right?
Should clisp then signal an error?
I don't know what the "right" answer would be. At times I like
promoting to the bigger type, but at other times, I like instantly
seeing when I've lost precision in clisp.
However, I have discovered the "errant" part of my program. I lose
precision because I had something like
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.