Re: comparison operators and *typos Chongkai Zhu (23 Jun 2005 03:17 UTC)
Re: comparison operators and *typos Aubrey Jaffer (24 Jun 2005 19:51 UTC)

Re: comparison operators and *typos Chongkai Zhu 23 Jun 2005 03:15 UTC

======= 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: =======
> | >...
> |
> | (= -0 0) should be #f.
>
>Then (eqv? -0 0) ==> #f; which will break much existing Scheme code
>which tests for 0.  The ZERO? procedure expects a number; one can test
>whether an arbitrary object is 0 with (eqv? obj 0).  Because of -0,
>this test must be replaced by (and (number? obj) (<= -0 obj 0)).

(and (number? obj) (zero? obj))

>
>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.

>
> | > | procedure: numerator q
> | > | procedure: denominator q
> | > |     These procedures return the numerator or denominator of their
> | > |     argument; the result is computed as if the argument was
> | > |     represented as a fraction in lowest terms.  The denominator is
> | > |     always positive or zero.  The denominator of 0 is defined to be
> | > |     1.
>
> (my-numerator |-0|)	==> 0
> (my-denominator |-0|)	==> 1
> (numerator 0)		==> 0
> (denominator 0)	==> 1

This is a bug of my implement. 'my-numerator should return an "exact-record"
instead of a "R5RS number". So (my-numerator |-0|) should be |-0|.

>
>If the NUMERATORs and DENOMINATORs of -0 and 0 are equal, then -0 and
>0 must be the same number.  But as you wrote, "(= -0 0) should be #f."
>
>If (< -0 0), then -0 must be negative; but:
>
>(my-negative? |-0|) ==> #f

"-0" is zero instead of negative.
>
>If (< -0 0), then (- 0 -0) must be nonzero; but
>
>(exact->string (my- 0 |-0|)) ==> "0"
>

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 ..." Obviously, exact infinities should be rational
infinities, or infinities in mathematical meaning. And the need for
exact infinities should not be oppugned (either for aesthetic reasons
or utility).

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.

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). This will
require the systme to support inner polar representation of complex
munbers that contains a hidden 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.

Any suggestions on exact infinity implementation details are welcome.
Maybe there should be better solutions.

-
Chongkai Zhu