| Date: Fri, 20 May 2005 10:28:12 +0800
| From: "Chongkai Zhu" <xxxxxx@citiz.net>
|
| I have also considered infinities in Scheme and have some different
| ideas:
|
| 1. We need both exact (rational) infinity and inexact infinity, that
| is, four special numbers:
|
| 1/0 -1/0 +inf.0 -inf.0
|
| The first two are rational and thus exact.
In math texts (http://en.wikipedia.org/wiki/Rational_numbers):
A rational number is a ratio or quotient of two integers, usually
written as the vulgar fraction a/b, where b is not zero.
| Even if this SRFI won't specify exact infinity, it should not use
| the "syntax of numerical constants" 1/0 and -1/0, but +inf.0 and
| -inf.0 instead, so that a latter SRFI can use 1/0 and -1/0 as exact
| infinity.
In hundreds of years of using rational numbers, mathematicians have
not discovered 1/0 to be a useful extension to the rational numbers.
| This also keeps the tradition that "x/y" (in which x and
| y are both integers) is a rational, and the syntax of an inexact
| constant contains a dot.
1/0 is very evocative for infinity. While "finit" is a Latin root,
"infinit" is a Middle English derivation. Thus "inf" will be not be
nearly as evocative for most people. More than programmers see data
written by programs.
How about "1/0." and "-1/0."?
| 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.
| There are two rationales for adding rational infinity: aesthetic and
| utilitarian. Aesthetically, the exact infinity and inexact infinity
| together keeps the distinction (between exact and inexact) orthogonal
| to the dimension of type. IMO, orthogonality is a character of Scheme
| and is always wanted.
Although R5RS states "This distinction is orthogonal to the dimension
of type", it is evidently a limited orthogonality. Operations
returning inexact numbers are allowed to return approximate results,
while operations returning exact numbers are not. [The orthogonality
sentence is removed by SRFI-70.]
Largely because of that orthogonality statement, there is a
groundswell of opposition to R5RS exactness in the Scheme community.
An example of this is the paper:
Sebastian Egner, Richard Kelsey, Michael Sperber:
Cleaning up the Tower: Numbers in Scheme,
The 2004 Scheme Workshop, Snowbird, Utah, October 2004.
http://www-pu.informatik.uni-tuebingen.de/users/sperber/papers/numerical-tower.pdf
which is discussed in SRFI-70. Kelsey was and Sperber is on the
Scheme Language Editors Committee.
| 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?
| 2. Since we have both positive infinity and negative infinity, we
| are forced to have two (or four, if exactness is also
| considered) zeroes: positive and negative. IMO, this model is
| more preferable than the "limit".
Limits are familiar to everyone who has studied the Calculus. To my
knowledge, limits have only been implemented on computers in symbolic
mathematics programs. To have them in Scheme may be an advancement.
| For example, in PLT Scheme:
|
| Language: Textual (MzScheme, includes R5RS).
| > (/ -0.0)
| -inf.0
| > (/ 0.0)
| +inf.0
| > (/ +0.0)
| +inf.0
| > (+ 0.0 -0.0)
| 0.0
|
| The only compromise is the last case: (+ 0.0 -0.0) evals to +0.0
|
| Other computation rules should be straight forward.
;; MzScheme version 205:
> (eqv? 0.0 +0.0)
#t
> (eqv? 0.0 -0.0)
#f
> (< -0.0 +0.0)
#f
> (* 2.0 -0.0)
0.0
> (/ 0.5 -0.0)
-inf.0
> (/ (* 2.0 -0.0))
+inf.0
