[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unifying the two generic arithmetic alternatives

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

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.