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

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.



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