[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comparison operators and *typos
> | 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
- 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:
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
- 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