# Re: comparison operators and *typos

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.

``` | Date: Thu, 30 Jun 2005 20:11:03 -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?

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

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

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

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

```