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

This page is part of the web mail archives of SRFI 73 from before July 7th, 2015. The new archives for SRFI 73 are here. Eventually, the entire history will be moved there, including any new messages.

*To*: "Aubrey Jaffer" <agj@xxxxxxxxxxxx>*Subject*: Re: comparison operators and *typos*From*: "Chongkai Zhu" <mathematica@xxxxxxxxx>*Date*: Thu, 23 Jun 2005 11:15:38 +0800*Cc*: "srfi-73" <srfi-73@xxxxxxxxxxxxxxxxx>*Delivered-to*: srfi-73@xxxxxxxxxxxxxxxxx

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

**Follow-Ups**:**Re: comparison operators and *typos***From:*Aubrey Jaffer

- Prev by Date:
**Revision of SRFI 73 available** - Next by Date:
**Re: comparison operators and *typos** - Previous by thread:
**Re: comparison operators and *typos** - Next by thread:
**Re: comparison operators and *typos** - Index(es):