| Date: Fri, 01 Jul 2005 13:06:59 -0400 | From: Paul Schlie <xxxxxx@comcast.net> | | > | > 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.
