[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My ideas about infinity in Scheme (revised)
| 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
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
| 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
| > (limit (lambda (x) (/ (sin x) x)) 0 1.0e-9)
| > (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)
| > (limit (lambda (x) (if (rational? x) 1 0)) 0 1.0e-9)
| 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 ].