[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comparison operators and *typos
| 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
#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
| > | (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.