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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Unifying the two generic arithmetic alternatives*From*: Dave Mason <dmason@xxxxxxxxxxxxxxx>*Date*: Tue, 15 Nov 2005 09:08:09 -0500*Comments*: In-reply-to Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx> message dated "Tue, 15 Nov 2005 05:29:09 -0800."*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051115132909.F06BD600037@xxxxxxxxxxxxxxxxxxxxxxx>*References*: <20051115132909.F06BD600037@xxxxxxxxxxxxxxxxxxxxxxx>

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. ../Dave

**Follow-Ups**:**Re: Unifying the two generic arithmetic alternatives***From:*Marcin 'Qrczak' Kowalczyk

**References**:**Re: Unifying the two generic arithmetic alternatives***From:*Andrew Wilcox

- Prev by Date:
**Re: Unifying the two generic arithmetic alternatives** - Next by Date:
**Re: Unifying the two generic arithmetic alternatives** - Previous by thread:
**Re: Unifying the two generic arithmetic alternatives** - Next by thread:
**Re: Unifying the two generic arithmetic alternatives** - Index(es):