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