Mark H Weaver <[email protected]> writes:
> The point of the exact/inexact distinction is to ensure that if you see
> an exact number, you can trust that it is provably the correct answer,
> and that no inaccuracies associated with inexact arithmetic along the
> way could possibly have corrupted that answer.
Yes, I think I understand that.
> In this case, the inaccuracies associated with inexact arithmetic could
> result in an infinity being misrepresented as a finite number, or vice
> versa. For example, if X is inexact, then we cannot claim that the
> result of (* 0 (/ X)) is an exact 0, because a small change in X could
> affect the final answer.
In other words, the argument is that any inexact number might actually
be infinite. (Right?)
That strikes me as stretching the idea of inexactness too far; and also
as not useful, because I'm sure there are many practical ways of
producing inexact numbers that are provably finite (e.g. sqrt(5)). My
guess is that for the majority of programming situations where I have an
inexact number X, that number is provably finite, and so I'd want (* 0
X) to be an exact 0.
But I'm not an expert, and I'm not actually writing those programs
now...
Are you following specific references here? FWIW, for cases like this,
the last para of R6RS 11.7.1 allows "either 0 (exact) or 0.0 (inexact)".
Neil
