Revision of SRFI 70 available Michael Sperber (18 Jul 2005 11:58 UTC)
Re: Revision of SRFI 70 available bear (18 Jul 2005 15:50 UTC)
inexactness vs. exactness Aubrey Jaffer (18 Jul 2005 23:57 UTC)
Re: inexactness vs. exactness bear (19 Jul 2005 02:31 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (21 Jul 2005 17:01 UTC)
Re: inexactness vs. exactness bear (22 Jul 2005 00:22 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (22 Jul 2005 16:01 UTC)
Re: inexactness vs. exactness bear (22 Jul 2005 16:21 UTC)
Re: inexactness vs. exactness Alan Watson (22 Jul 2005 18:21 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (25 Jul 2005 03:38 UTC)
Re: inexactness vs. exactness bear (27 Jul 2005 16:03 UTC)

Re: inexactness vs. exactness bear 22 Jul 2005 00:22 UTC


On Thu, 21 Jul 2005, Aubrey Jaffer wrote:

>You are suggesting that an implementation in which inexact numbers are
>not neighborhoods can conform to R5RS.  I will show that this is
>impossible.
>
>If real inexacts are not neighborhoods, then they correspond to single
>mathematical numbers (points).
>
>The number of inexact numbers possible in this hypothetical system is
>either finite or not.
>
>Finite number of inexacts:
>
>  There are an infinite number of possible continuous formulas (Scheme
>  procedures) yielding distinct values when applied to inexact
>  arguments.  If the number of possible inexact numbers is finite,
>  then an infinite number of the formula results must map to the
>  finite inexacts; and (because of continuity) they must be
>  neighborhoods.

You are confusing the limitations of real hardware with the specification
in order to arrive at a false dilemma.  The standard allows implementations
to regard every inexact number as (say) negative nineteen and still be
compliant; inexactness means simply that there is a chance (in such a
boneheaded implementation a near certainty) that the inexact number is
wrong.

Now, you can regard this single-valued inexact number system as the
ultimate "neighborhood", or you can regard it as being potentially
wrong; IMO, the standard does the latter.

>Infinite number of inexacts:
>
>  There are an infinite number of possible formulas (Scheme
>  procedures) involving transcendental functions yielding distinct
>  values when applied to inexact arguments.
>
>    R5RS 6.2.2 Exactness states:
>
>    If two implementations produce exact results for a computation
>    that did not involve inexact intermediate results, the two
>    ultimate results will be mathematically equivalent.  This is
>    generally not true of computations involving inexact numbers since
>    approximate methods such as floating point arithmetic may be used,
>=>  but it is the duty of each implementation to make the result as
>=>  close as practical to the mathematically ideal result.
>
>  By R5RS 6.2.2, if a transcendental function returns an approximate
>  result, then it must map to the nearest inexact number.  Thus
>  inexacts designate their closest neighborhoods.

No, this just says that you acknowledge the answer is wrong,
but exhorts you you try to make the system something other than
totally useless.  This doesn't make the inexact numbers into
"neighborhoods," it just means that the exact answer is not
representable so we're giving a wrong answer and we're going
to get as close to the correct answer as we can. If your only
representable inexact number is minus nineteen, then that's
what you return; but you don't make it exact, because that
would be claiming that it were the correct answer.

>So, not only is it proved that:
>
>* Scheme inexact real numbers correspond to real neighborhoods;

You've proved no such thing.  Inexact has no meaning other
than "this answer may be wrong."

				Bear