This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
| 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 ].