[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unifying the two generic arithmetic alternatives
Andrew Wilcox wrote:
> From the responses so far,
> (exact? "a string")
> appears to be immediately confusing to most people.
Well, it is always #t. But:
(exact? (expression yielding string result))
may not be, if the expression uses inexact operations.
Sorry I haven't been following the (rather long, detailed) discussion
here, but I would love to see this proposal in effect. It's important
that people be able to express the inexactness of their calculations -
regardless of the type of the result.
Among other things it would be desirable from a program verification
standpoint. If I have a test suite that claims that a test passes but
in reality it is dependent on the actual values of operands of inexact
operations, I would really want to know that. Which arises from a
(possibly even stranger, but possibly more clear) expression:
(exact? (expression yielding boolean))
possibly yielding (exactly!) #f
There was a language called Numeric Turing in the 80's that had similar
ideas, although not carried as far. It was oriented to proofs of
correctness, including the degree of exactness of results.
I also do similar things with probabilistic execution of programs -
conditionals return 'maybe' values with probability distributions
associated with them.