[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.