Re: comparison operators and *typos

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | 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.