Comparing float to rational

[Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>]

    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