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

Re: Contagious Inexactness, revision 2

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.



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.