Re: inexactness vs. exactness William D Clinger (27 Jul 2005 06:48 UTC)
Re: inexactness vs. exactness Michael Sperber (27 Jul 2005 15:22 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (31 Jul 2005 02:37 UTC)
Re: inexactness vs. exactness bear (31 Jul 2005 06:20 UTC)
Re: inexactness vs. exactness Paul Schlie (31 Jul 2005 13:51 UTC)
Re: inexactness vs. exactness bear (31 Jul 2005 18:47 UTC)
Re: inexactness vs. exactness Paul Schlie (01 Aug 2005 02:17 UTC)

Re: inexactness vs. exactness bear 31 Jul 2005 06:20 UTC

I know that it's not the right thing in all cases and all times,
but I think it's a good thing in most of the cases I use, for
an operation on exact arguments whose mathematically correct
result is too large to be represented as an exact number, to
(silently) return an inexact number of the highest available
precision.

Thus, precision escalating out of control in an iterative
algorithm using rationals eventually breaks a point where
the denominator is more than three hundred digits long,
and instead of crashing or bogging down with ever-larger
diophantine fractional calculations, and an addition or
a multiplication or whatever returns a float.

This behavior is neither mandated nor forbidden by R5RS.  I
think that's a good thing.  Your proposal also does not
mandate nor forbid it; I think that's a good thing too. But
it sounds like you came really close to forbidding it, and
may have failed to do so only by accident.  So I just wanted
to point it out as a frequently desirable behavior.

			Bear