| Date: Thu, 23 Jun 2005 11:15:38 +0800
| From: "Chongkai Zhu" <xxxxxx@citiz.net>
|
| ======= At 2005-06-22, 00:44:30 Aubrey Jaffer wrote: =======
|
| > | Date: Mon, 20 Jun 2005 12:48:21 +0800
| > | From: "Chongkai Zhu" <xxxxxx@citiz.net>
| > |
| > | ======= At 2005-06-20, 10:06:21 Aubrey Jaffer wrote: =======
| > ...
| >Another example where -0 breaks existing code is:
| >
| > (case val
| > ((0) ...)
| > ((1) ...)
| > (else ...))
| >
| >will not match when VAL is -0.
| >
| >(exact->string (my* -5 0)) ==> "-0". So -0 will occur often.
|
| Yes. Some existing code will be broke up.
It is a bad idea to break a large portion of existing Scheme programs
for a feature whose worth is unproven.
| ...
| Adding a "-0" does cause some strange result. But it is a
| compromise to allow -1/0. Here I would like to say more about it.
|
| First, when I saw your SRFI-70, I realized that there should not
| only be inexact infinities in Scheme, but also exact infinities.
| As SRFI-70 says, "The interpretation of real infinities is that 1/0
| represents real numbers greater than can be encoded by finite
| inexacts in the implementation ..."
That is why infinities are inexact. Each exact number represents
exactly one mathematical number.
| Obviously, exact infinities
| should be rational infinities, or infinities in mathematical
| meaning.
In standard analysis "infinity" isn't a number; it is the behavior of
a limit.
| And the need for exact infinities should not be oppugned
| (either for aesthetic reasons or utility).
I don't feel any "need for exact infinities".
| Then comes the pragmatic problem, the details. Two ideas comes to
| my mind. One is from Richard J. Fateman and his paper at
| http://www.cs.berkeley.edu/~fateman/papers/extrat.ps , and is what
| I used now in SRFI-73. As you pointed out, it is not backward
| compatible. The problem comes from "-0", the reciprocal of "-1/0".
| But there are also reasons for supporting it.
Fateman claims he is "forced to have two zeros", but gives no
justification for that statement:
In the affine model, we have both positive infinity 1/0 and negative
infinity (-1/0). Consequently we are forced to have two zeroes:
positive 0 (represented by 0/1) and negative (-0) (represented by
0/-1). Among other reasons for preferring it, this model is more
suited to transcendental functions [6] allowing one to describe
branch cuts more specifically.
SRFI-70 inexacts work well with just one zero (interval). Because
SRFI-70 inexacts do not add any new elements the field of real
numbers, they do practically no damage to arithmetic.
Having two zeros does major damage. If something must be broken, then
having the reciprocal of 1/0 and -1/0 both map to 0 is far better,
preserving arithmetic expectations and the existing body of Scheme
code.
| Another ideas originates when I implement MrMathematica. This one
| is more mathematical "right", but will be somewhat unefficient.
| The principle is, only define one exact infinity, "1/0", the
| positive infinity, and use polar coordinates to represent
| numbers(other infinities).
Complex infinities are considered in the "Infinities" section of
SRFI-70, but there are complications. The approach angles of complex
limits become quantized at small increments. Also, LIMIT is based on
the Mean-Value Theorem; what is the complex analog?
| This will require the system to support inner polar representation
| of complex munbers that contains a hidden PI.
Good point! An alternative is having an exact PI.
| Now negative
| infinity can be represented as (make-polar #e1/0 1); complex
| infinity (undirected infinity) can be represented as (make-polar
| #e1/0 #i0/0). One of the problem of this model is that it needs
| even bigger change on most existing Scheme system to support it.
Inexact complex infinities might work; but exact complex infinities
will not because the functions converting between rectangular and
polar forms are transcendental! Those transcendental functions return
inexact numbers for essentially all inputs.
