> | From: Paul Schlie <xxxxxx@comcast.net> > | > | ... 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
