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

*To*: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA*Subject*: Comparing float to rational*From*: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>*Date*: Tue, 28 Jan 86 14:56 EST*In-reply-to*: <860127175030.6.GLS@THINK-JEHOSEPHAT.ARPA>*Reply-to*: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

Date: Mon, 27 Jan 86 17:50 EST From: Guy Steele <gls@THINK-AQUINAS.ARPA> I thinm that Fateman has raised a valid issue that deserves discussion. Right now the Common Lisp book does seem to specify quite clearly (page 194) that for comparison as well as "combining" of a rational with a float, the rational shall be converted to a float of the same format. Evidence on the other side of the question is the remark that for MAX and MIN, if the largest (resp. smallest) argument is a rational then the returned result may be a rational even though the argument is a float. I think there is a lot to be said for requiring comparison between a rational and a float always to work and not to overflow. I think there is much less to be said in the case of addition, but I am on less solid ground here. What is FORTRAN's position on this? In FORTRAN when an integer meets a float, the integer gets converted to a float. I can't find my copy of the FORTRAN '77 standard just this minute, but I don't recall anything in the standard requiring the range of a float to be as large as that of an integer (granted that for an integer to exceed the range of a float would be considered unusual in that culture). Right. In the land of Fortran machines, integers can't overflow when converted to floats. But, speaking of Fortran, perhaps overflow considerations are where the coercion rules came from -- integers don't overflow when converted to singles, and singles don't overflow when converted to doubles. Now that we have bignums, the ground rules are different and we can rethink the rules. I also reject the notion that a floating-point number is really an interval (though I'm not sure GJC implied this directly). However, I do think it is reasonable to consider floating-point numbers to be approximations--at least, once the inexact flag gets set. (It seems to me, by the way, that if bits were free it would be more sensible to have an inexact bit in every value rather than a single global flag; but bits are not free and the 754 committee was having to sweat as it was to cram everything into 32 bits.) One strives for a reasonable economic balance between accuracy, speed, and ease of understanding. In the case of comparisons, it is not too difficult to be completely accurate, and doing so makes it much easier to understand. That's as far as I go with confidence. The issue for addition or multiplication is not so clear, because the speed costs are not clear (they can cascade). This is a reasonable matter for discussion. --Guy

**References**:**Comparing float to rational***From:*Guy Steele <gls@THINK-AQUINAS.ARPA>

- Prev by Date:
**IEEE float co-processors** - Next by Date:
**comparisons between floats and ratios** - Previous by thread:
**Comparing float to rational** - Next by thread:
**:capitalize in *print-case*** - Index(es):