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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Contagious Inexactness, revision 2*From*: Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>*Date*: Thu, 17 Nov 2005 05:22:42 -0800 (PST)*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

I wrote: > Two Scheme implementations returning results flagged as exact, from > the same computation, performed on the same inputs, will return > equal values. Marcin 'Qrczak' Kowalczyk writes: > I believe this is unimplementable sanely. > > (define (test) > (let ((l '())) > (if (= (expt (sqrt 2) 2) 2) > (set! l (cons #f l))) > (length l))) > > Does this return an inexact 0 or 1? If yes, how would you implement > this? Zounds! You are entirely correct. We can also use an escape continuation to defeat the assertion: (call/cc (lambda (return) (if B (return 1) 2))) Can the assertion be rewritten to enumerate the cases in which which the result of a computation being marked as exact *does* imply that two Scheme implementation would return the same result? I'm not too worried about your example of SET! in an IF branch, or my example of an escape continuation. Both are using the IF not to select a return value, but to choose whether or not to perform an action. No one is surprised that, for example, the standard algebraic laws don't hold in such expressions either. However, it seems to me that the contagious inexactness proposal is only going to be of practical usefulness if: * the conditions under which the assertion holds are clear and easy to understand, and * it is easy to write an expression that satisfies the conditions Otherwise, you're not going to be able to trust an exactness result if you can't easily look at a program and tell whether it's valid.

- Prev by Date:
**Re: Contagious Inexactness, revision 2** - Next by Date:
**Generic Exact Arithmetic** - Previous by thread:
**Re: Contagious Inexactness, revision 2** - Next by thread:
**Contagious Inexactness: dealing with conditionals** - Index(es):