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

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

*To*: schlie@xxxxxxxxxxx*Subject*: Re: comparison operators and *typos*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 1 Jul 2005 21:06:16 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BEEAF073.AB1A%schlie@xxxxxxxxxxx> (message from Paul Schlie on Fri, 01 Jul 2005 13:06:59 -0400)*References*: <BEEAF073.AB1A%schlie@xxxxxxxxxxx>

| Date: Fri, 01 Jul 2005 13:06:59 -0400 | From: Paul Schlie <schlie@xxxxxxxxxxx> | | > | > If we make (/ +1 0.0) ==> #i+1/0, then (/ -1 0.0) ==> #i-1/0. | > | > This choice is arbitrary; ... | > | | > | - which seems very reasonable. | > | | > | > | > Inexact infinities have reciprocals: zero. Their reciprocals | > | > | > are not unique, but that is already the case with IEEE-754 | > | > | > floating-point representations: | > | > ... | > | > Zero is at the center of 0.0's neighborhood. R5RS division by 0.0 | > | > is an error; leaving latitude for SRFI-70's response. | > | | > | - also seems very reasonable, and provide the opportunity to reconsider | > | eliminating IEEE-754's otherwise inconsistent asymmetry, by defining: | > | | > | (/ #i-0/1) => #i-1/0 ; -inf.0 | > | (/ #i+0/1) => #i+1/0 ; +inf.0 | > | | > | thereby truly consistently symmetric with the above: | > | | > | (/ #i-1/0) => #i-0/1 ; -0.0 | > | (/ #i+1/0) => #i+0/1 ; +0.0 | > | > It does not remove the asymmetry -- which neighborhood does | > (unsigned) 0.0 belong to: -0.0 or +0.0? | | - sorry, the answer was hidden on the last line below: 0.0 == +0.0 | | (which is the presumption of fp implementations which support -0.0, | which to me is confusing as then there is no value which is defined | which covers both +-0, hence the notion of ~0.0) In SRFI-70, both +0 and -0 would be within the neighborhood around 0.0 represented by 0.0. | > | > Most neighborhoods mapping through piecewise-continuous functions | > | > project onto adjacent neighborhoods. But / near 0 is not the | > | > only function which does not. TAN near pi/2 is another example. | > | | > | - and please reconsider this may be consistently symmetrically | > | defined: [where ~ denotes a value being simultaneously | > | positive and negative] | > | | > | (/ #i~0) => #i~1/0 ; ~inf.0 | > | (/ #i~1/0) => #i~0 ; ~0.0 | > | > #i~0 is not a real number because it cannot be ordered (relative to | > 0.0). Damaging the total ordering of the real numbers is too high a | > price for symmetry. | | - you may be correct, but can you provide an example of a practical | problem it would introduce, as I can't honestly think of one? Several difficulties with -0.0 not equal to 0.0 were shown in <http://srfi.schemers.org/srfi-73/mail-archive/msg00002.html> #i~0 adds further complications with comparisons: Is #i~0 less than, equal to, or greater than 0.0? Is #i~0 an integer? | (as to me, it seems that it may be thought of as simply a synonym | for the abstraction of the combined ordered regions +-0, which are | well ordered both between themselves, and all other numbers, and | seems consistent with the notion that #e0 is the center of ~0.0) | | > | (tan pi/2) => #i~1/0 ; ~inf.0 | > | > (atan #i+1/0) ==> 1.5707963267948965 | > | > The next larger IEEE-754 number is 1.5707963267948967. | > But there is no IEEE-754 number whose tangent is infinite: | > | > (tan 1.5707963267948965) ==> 16.331778728383844e15 | > (tan 1.5707963267948967) ==> -6.218352966023783e15 | | - personally, I see no reason to restrict scheme to IEEE-754 | idiosyncrasies or failures; TAN not reaching #i+/0 is a simple matter of the mantissa not having enough resolution around 1.5708. With a 12.bit exponent, over 1024.bit precision would be needed for a floating point number to have an infinite TANgent. | and as noted #i~1/0 may be though of as NAN, which is what IEEE-754 | considers both it and 1/0 to be, so it's actually more consistent | than it may first appear. In IEEE-754 the result of 1.0/0.0 is positive infinity, +inf, not NAN. | > Note that the one-sided LIMIT gets it right without needing any new | > numbers: | > | > (limit tan 1.5707963267948965 -1.0e-15) ==> +1/0 | > (limit tan 1.5707963267948965 1.0e-15) ==> -1/0 | | - yes, which is why the simultaneous two sided limit == +-1/0 == ~1/0 By the definition, the two-sided limit of tan at pi/2 does not exist because the one-sided limits are not equal. | and correspondingly (/ (tan pi/2)) => ~0 thereby all functions | may be thought of as being evaluated about simultaneously | converging points about their specified values | (f x y) == (f (+ x ~0.0) (+ y ~0.0)). | including (tan (+ pi/2 ~0.0)) ~0.0 will be much smaller in magnitude than the LSB of the floating-point neighborhood containing pi/2. So the ~0.0 will just disappear when added to pi/2. | and (/ 1 #e0) == (/ 1 (+ #e0 ~0.0)) == #i~1/0 == ~inf.0 Knowing that the value of an expression could be positive infinity or negative infinity is much less useful than knowing which infinity it is. | > | (abs ~inf.0) => +inf.0 | > | (- (abs ~inf.0) => -inf.0 | > | (abs ~0.0) => +0.0 | > | (- (abs ~0.0)) -0.0 | > | | > | (+ +0.0 -0.0) => ~0.0 | > | | > | Where I believe it's reasonable to redefine the use of IEEE's NAN | > | values to encode these values, as arguably ~inf.0 may be thought | > | of as being NAN, and ~0.0 as being 1/NAN (leaving 0.0 == +0.0) | > | > For some expressions returning #i0/0, no number has any more claim to | > correctness than any other. For example any number x satisfies: | > | > 0*x=0. | > | > So #i0/0 could be any number (if we forget that division by zero is | > undefined). The reciprocal of this #i0/0 potentially maps to any | > number; which is represented by #i0/0. | | - As I presently believe it's important to adopt a uniform convention | which dictates how multi-variable values are evaluated, using the | the convention above, which I believe to be most generally useful: | then #i0/0 == 1, if one considers the signs of the converging difference | in magnitude of a multi-variable function to uniform albeit ambiguous, | thereby, the ratio of: 0/0 == 1 == 100%, thereby 100% of 0/0 == 0, not | some useless error. It can be useful to have an inexact number which stands in for a numerical result about which there is no information. #i0/0 is that number in SRFI-70. As SRFI-70 states: "0/0 can be considered an error waiting to happen." The 0/0 you are writing about is quite different. | or 0/0 == ~1, if the their signs are not necessarily considered | uniform. which is likely most technically correct, and yields: | ~100% of 0/0 == ~0, but I know you're not too enthusiastic about | ~1 which I avoided earlier, by only introducing ~0 which happens | to represent a pair of ordered values with no intervening | potential ordering ambiguity to speak of.

**Follow-Ups**:**Re: comparison operators and *typos***From:*Paul Schlie

**References**:**Re: comparison operators and *typos***From:*Paul Schlie

- 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):