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

*To*: mathematica@xxxxxxxxx*Subject*: Re: comparison operators and *typos*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 24 Jun 2005 15:50:54 -0400 (EDT)*Cc*: srfi-73@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-73@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050623031600.80DD8135@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (mathematica@xxxxxxxxx)*References*: <20050623031600.80DD8135@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

| Date: Thu, 23 Jun 2005 11:15:38 +0800 | From: "Chongkai Zhu" <mathematica@xxxxxxxxx> | | ======= 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: ======= | > ... | >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.

**References**:**Re: comparison operators and *typos***From:*Chongkai Zhu

- Prev by Date:
**Re: comparison operators and *typos** - 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):