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

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.

*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):