Re: comparison operators and *typos Paul Schlie 01 Jul 2005 17:06 UTC

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