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 Paul Schlie 31 Jul 2005 13:51 UTC

> From: bear <xxxxxx@sonic.net>
> 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.

- As personally I think it's poor idea to place the responsibility
  to limit the precision of exact data such that calculations will
  not exceed the practical physical limitations of an exact
  implementation's representational capabilities on the programmer,
  but rather believe that it's the responsibility of the implementation
  to endeavor to limit the precision of an exact value's representation
  to some practical physical limit in an effort to prevent such
  scenarios; I'd rather see it become acceptable that an exact
  implementation may return an imprecise exact value limited to some
  implementation defined precision limit, where the precision limit
  of an exact value's representation is presumed to be greater than
  the precision supported by an inexact value's representation.

  Thereby enabling the specification/calculation of values potentially
  greatly exceeding the precision offered by an inexact implementation,
  while relieving the the programmer from the otherwise implied
  responsibility of having to somehow pre-cognitively prevent the
  specification of the calculation of potentially irrational values.

  As this would imply that such an exact implementation may have some
  practical precision limit, it correspondingly must either be defined
  to have the same representational magnitude bounds as an inexact
  implementation, or by implication have distinct infinite and reciprocal
  bounds defined. (where the former seems simplest, although apparently
  only suggested in jest earlier).