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

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: comparison operators and *typos*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Fri, 01 Jul 2005 13:06:59 -0400*Cc*: <srfi-70@xxxxxxxxxxxxxxxxx>*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050701033224.2770B1B77B4@xxxxxxxxxxxxxxxx>*User-agent*: Microsoft-Entourage/11.1.0.040913

> | > 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) > | > 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? (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; 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. > 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 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)) and (/ 1 #e0) == (/ 1 (+ #e0 ~0.0)) == #i~1/0 == ~inf.0 > | (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. 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:*Aubrey Jaffer

**References**:**Re: comparison operators and *typos***From:*Aubrey Jaffer

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