[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comparing float to rational
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.