Re: comparison operators and *typos

[Paul Schlie <schlie@xxxxxxxxxxx>]

>  | From: Paul Schlie <schlie@xxxxxxxxxxx>
>  | 
>  | ... it seems both reasonable and useful to define:
>  | 
>  |   (= -0.0 0 0.0) => #t
>  |   
>  |   thereby zero's are considered to compare equal, enabling (= 0 any-zero)
>  | 
>  |   (< -0.0 0.0) => #t
>  |   (> 0.0 -0.0) => #t
> 
> Mathematically, `=', `<', and `>' are mutually exclusive.  So -0.0
> cannot simultaneously be `=' and `<' 0.0.

- why not? as it seems useful; any practical example to the contrary?

>  |   thereby only regions which do not overlap compare < or >
> 
> So what is returned by comparisons of overlapped regions?

- for ordered comparisons excluding equivalence, they return false.

>  |   (<= -0.0 0 0.0) => #t
>  |   (>= 0.0 0 -0.0) => #t
>  | 
>  |   thereby only 0 is (and (<= x 0.0) (>= x -0.0))
> 
> That could only be true if 0 is not within any inexact neighborhood.
> It would then be the only real number for which EXACT->INEXACT fails
> to return a value.
> 
> Because (= -0.0 0.0), x can also be 0.0; and (<= 0.0 -0.0) should also
> return true.  We have thus reached a situation where -0.0 and 0.0 are
> indistinguishable.

- thereby as noted only:  -0.0 is (and (= x 0) (< x 0))
  and correspondingly only 0.0 is (and (= x 0) (> x 0))

>  | > | >   (tan 1.5707963267948965) ==> 16.331778728383844e15
>  | > | >   (tan 1.5707963267948967) ==> -6.218352966023783e15
>  | > TAN not reaching #i+/0 is a simple matter of the mantissa not having
>  | > enough resolution around 1.5708.  With an 11.bit exponent, over
>  | > 1024.bit precision would be needed for a floating point number to have
>  | > an infinite TANgent.
>  | 
>  | - are you saying that since pi/2 can't be represented with sufficient
>  |   precision to yield:
>  | 
>  |   (tan (+ pi/2 0.0)) -> inf.0, or (tan (- pi/2 0.0)) => -inf.0
>  | 
>  |   that they shouldn't be formally defined to be so?
> 
> No amount of precision will make (+ pi/2 0.0) return a different
> number from (- pi/2 0.0).

- (tan (+ pi/2 0.0)) will be negative and technically infinite.

  (tan (- pi/2 0.0)) will be positive and technically infinite.

  therefore the difference between the two values is technically infinite?
  (which seems like a pretty big difference to me?)

>  |   which I'd disagree with, as although I accept that a particular
>  |   implementation may not have sufficient precision to exceed the
>  |   dynamic range of the representation, therefore may only yield
>  |   smaller values; I don't believe it's correct to define (tan pi/2)
>  |   as being anything other than <+|->inf.0 (aka ~inf.0, or e~/0).
> 
> Mathematically, tan(pi/2) is undefined.

- unless one can define a value which can consistently represent both
  positive and negative infinity, such as ~inf.0 (aka e~/0)

>  | >  | > 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.
>  | 
>  | - really, I was under the impression that they were?
> 
> Look it up: <http://en.wikipedia.org/wiki/Limit_of_a_function>

- yes, and correspondingly:
  
http://en.wikipedia.org/wiki/How_to_evaluate_the_limit_of_a_real-valued_func
tion

  particularly: "Limits do not always exist", in the absents of being able
  to denote a value which has an ambiguous sign, i.e.: ~inf.0, ~1.0, etc.
 
  and: "L'Hôpital's rule, and division by zero", which then clearly enables
  the definition of (tan x) as (/ (sin x) (cos x)), as x -> pi/2, in
  combination with the above, enabling the precise result of ~inf.0.

>  |   for example if I defined an inexact number system based on binary
>  |   fractions of pi, then it would only require a few bits of
>  |   precision to represent pi/2 exactly, and produce fully symmetric
>  |   results for (tan x) which would be equal to <+|->inf.0 at pi/2.
> 
> Mathematically, tan(pi/2) is undefined; but the one-sided limits tend
> to positive infinity and negative infinity.  Going to great lengths to
> have pi/2 in your number system so that tan(pi/2) can return an
> infinity with indeterminate sign is computationally useless.
> SRFI-70's #i0/0 is sufficient to represent any indeterminate quantity.
> That there are finer shades of distinction for indeterminates is
> perhaps interesting, but certainly not a necessity for R6RS.

- tan(pi/2) is well understood to be -inf.0 if approached from the left,
  and +inf if approached from the right, therefore correspondingly well
  defined as ~inf.0, if such a value representation were defined. (which
  seems perfectly reasonable as it would be equivalent to the reciprocal
  of the values about absolute 0, who's reciprocal is not +inf.0 as
  incorrectly presumed in many implementations.)

>  | >  |   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.
>  | 
>  | - agreed, but without being able to determine the sign of a zero,
>  | which I agree is often not important, you can't determine the sign
>  | of it's reciprocal which is an infinity, (so the problem is fully
>  | symmetric, if signs of infinities are likely important, then so are
>  | the signs of zeros it would seem.)
> 
> Inexact numbers are approximate.  Most calculations returning inexact
> numbers lose information.  Which side the zero, pi, or other number
> was approached from is one of the casualties of approximate computing.

- producing a sign about any value seems egregious, as it represents an
  instantaneous loss of indefinite precision; even about 0, as it's
  reciprocal would be then potentially be absolutely incorrect.

> One must be careful with numerical properties.  If I understand your
> system, adding -0.0 to 0.0 returns -0.0.

- no, I'd likely define that (+ -0.0 0.0) => ~0.0; as 0.0 == +0.0,

  thereby: (+ -0.0 +0.0) ::
  (+ (+ -0.0 ~0.0) (+ +0.0 ~0.)) ::
  (+ [(+ -0.0 +0.0) or (+ -0.0 -0.0)] [(+ +0.0 +0.0)or (+ +0.0 -0.0)]) ::
  (+ [-0.0 or 0] [+0.0 or 0]) ::
  [(+ -0.0 +0.0) or (+ -0.0 0) or (+ 0 +0.0) or (+ 0 0)] ::
  [[self] or -0.0 or +0.0 or 0] => ~0.0

>                                         But that -0.0 may have been
> generated by (* -5 0.0) while the 0.0 was the result of (/ #i+1/0).
> Taking the reciprocal of the resulting -0.0 will be the wrong
> infinity.  Just because an attribute is there, doesn't mean it is
> reliable.

- no as: (+ (* -5 0.0) (/ #i+1/0)) :: (+ -0.0 +0.0) => ~0.0
 
> (/ (+ (* -5 0.0) (/ #i+1/0)))

  :: (/ ~0.0) => ~inf.0

  [thereby although the absolute sign has been lost, it's correctly
  attributed as being ambiguous, thereby any subsequent uses of it's
  value will have a corresponding ambiguity]

  :: (/ -0.0 (/ +inf.0)) :: (/ -0.0 +0.0) => ~0.0