Re: My ideas about infinity in Scheme (revised)

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | Date: Mon, 23 May 2005 13:33:49 +0800
 | From: "Chongkai Zhu" <mathematica@xxxxxxxxx>
 |   
 | ======= Aubrey Jaffer wrote: =======
 | > 
 | >  | Date: Fri, 20 May 2005 10:28:12 +0800
 | >  | From: "Chongkai Zhu" <mathematica@xxxxxxxxx>
 | > 
 | >  | For the same reason, the syntax of "indeterminate" should be "0/0"
 | >  | (exact) and "nan.0" (inexact).  The names +inf.0, -inf.0 and nan.0
 | >  | were borrowed from PLT scheme.
 | > 
 | > While the number syntax of R5RS can be readily extended to include
 | > +inf.0, -inf.0 (because of the leading sign). "nan.0" runs afoul of
 | > R5RS 2.1 Identifiers:
 | > 
 | >    ... in all implementations a sequence of letters, digits, and
 | >    "extended alphabetic characters" that begins with a character that
 | >    cannot begin a number is an identifier.
 | > 
 | > If NAN.0 is syntactically a number, then NOT, NULL-ENVIRONMENT, NULL?,
 | > NUMBER->STRING, NUMBER?, and NUMERATOR are not identifiers.
 | 
 | PLT Scheme has both "+nan.0" and "-nan.0", and it actually doesn't have
 | "nan.0". So actually it doesn't run afoul of R5RS. A tricky solution.

In MzScheme version 205:

-nan.0                  ==>  +nan.0
(eq? +nan.0 -nan.0)	==>  #t

 | >  | Another rationale is utility.  For example, interval arithmetic
 | >  | will need exact infinity.
 | > 
 | > I have used interval arithmetic in Scheme (coding #f for infinity).
 | > Why does it need exact infinity?
 | 
 | Although you use #f for infinity, it means an exact infinity.

You have not seen the interval arithmetic implementation I used.
Don't presume to know its details.

 | If we have exact infinity, than an interval is a pair of two rational,
 | which will simplify the code of interval arithmetic (and made it more
 | readable).

In the interval arithmetic package I used, all rational non-integers
were inexact.  Thus an interval could be designated by two inexact
real numbers; which would include the two real infinities.

 | But how can you ensure the limit always return the right answer?  I
 | read the reference implementation only to find that it is a
 | numerical one and can be easily cheated.

It is possible to fool LIMIT, but it is possible to fool any
programmed transcendental function.  The rewritten specification of
limit (Re: [srfi-70] Limit) is much clearer about its conditions for
operation.

 | AFAIK, CASs do some limits symbolically.  And I can accept a CAS
 | give some wrong result (even different CASs return different result
 | giving the same input).  But Scheme can't do so.  Then must be an
 | exact algorithm to do each thing in a Scheme spec!

All the inexact operations and functions in Scheme return approximate
presults.

 | > (limit (lambda (x) (/ (sin x) x)) 0 1.0e-9)
 | 1.0
 | > (limit (lambda (x) (/ (sin x) x)) 0 1)
 | bug /: division by zero

The revised LIMIT has a provision:

    z2 should be chosen so that proc is expected to be monotonic or
    constant on arguments between z1 and z1 + z2.

So LIMIT gets it correct with a z2 (much) smaller than 1.

 | > (limit (lambda (x) (if (exact? x) 1 0)) 0 1.0e-9)
 | 0
 | > (limit (lambda (x) (if (rational? x) 1 0)) 0 1.0e-9)
 | 1
 | 
 | Note that the final case can't be solved with any numerical method.

I will add a provision:

  PROC must be continuous on the half-open interval ( Z1 to Z1 + Z2 ].