Rationalize

["Robert A. Cassels" <Cassels@SCRC-QUABBIN.ARPA>]

    Date: Tue, 28 Aug 84 10:23 EDT
    From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>

    Just as another spot-check of portability, I tried out the slisp
    definition of "rationalize" in the Symbolics CLCP, and it works.

    However, on some hard cases (cases with large numerators and
    denominators), it gets different answers than ours.  For example, both
    functions, given 1.6666666, return 5/3.  However, if you lop off one 6
    and try 1.666666, ours gets 798918/479351 whereas yours gets
    873813/524288.  In octal, that's 3030306/1650167 for ours and
    3252525\2000000 for yours, which may be more revealing.  Anyway, doing
    the divisions back, using double precision, ours gives
    1.666666030883789d0 (3.088d0 error), and yours gives 1.666659712820042d0
    (2.872d0 error).  I'm not sure what the significance [I know] of this is.

Either is acceptable to CL:

"[RATIONALIZE] ... may return any rational number for which the
floating-point number is the best available approximation of its format;
... it attempts to keep both numerator and denominator small."

Ours is defined to be the fraction of smallest denominator which lies in
the "floating-point interval" around the argument.  It is definitely not
the most accurate.  But of course the most accurate rational
approximation to a floating-point number F is (RATIONAL F).  Ours
derives from RWG's paper on continued fractions wherein he shows how to
solve such important questions as, "If a baseball player is hitting
.319, what is the smallest number of at-bats he could have had?"

So we subscribe to the view that, "... RATIONALIZE goes to more trouble
to produce a result that is more pleasant to view ...".  You'll have to
decide for yourself whether 798918/479351 is more pleasant than
873813/524288.