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