This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
> From: bear <bear@xxxxxxxxx> > 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).