[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comparison operators and *typos

This page is part of the web mail archives of SRFI 73 from before July 7th, 2015. The new archives for SRFI 73 contain all messages, not just those from before July 7th, 2015.



  
======= At 2005-06-22, 00:44:30 Aubrey Jaffer wrote: =======

> | Date: Mon, 20 Jun 2005 12:48:21 +0800
> | From: "Chongkai Zhu" <mathematica@xxxxxxxxx>
> | 
> | ======= 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