| Date: Mon, 04 Jul 2005 13:49:25 -0400 | From: Paul Schlie <xxxxxx@comcast.net> | | > | 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? You are proposing to change the rules of real ordering. We can't read your mind; you need to explicitly describe your new rules if we are to intelligently discuss them. I am looking for something like "The procedure `=' returns #t if its arguments are within an infinitesimal of each other in value." And a description of infinitesimals, and their behavior when arithmetically combined with real numbers. I expect it will be difficult to combine infinitesimals with inexact numbers, which represent intervals on the real number line. | ... | > | > | > (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?) My statement did not involve TAN. How is the value of (+ pi/2 0.0) different from the value of (- pi/2 0.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_function | | 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. Their "Limits do not always exist" section does not mention anything about ambiguous signs. | 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. The piecewise continuous function (lambda (x) (+ 4 (/ (abs x) x))) has different one-sided limits at 0.: (limit (lambda (x) (+ 4. (/ (abs x) x))) 0. -1e-9) ==> 3.0 (limit (lambda (x) (+ 4. (/ (abs x) x))) 0. 1e-9) ==> 5.0 How will your system represent ((lambda (x) (+ 4. (/ (abs x) x))) 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, And so it is with SRFI-70: (limit tan 1.5707963267948965 -1.0e-15) ==> +1/0 (limit tan 1.5707963267948965 1.0e-15) ==> -1/0 | 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.) Mathematically there is no reciprocal of zero. It can be argued that (/ 1.0 0.0) should return #i0/0 or signal an error. But (/ 1.0 +0.0) should return #i1/0 if +0.0 is greater than 0. | > ... | > 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, The inexact real field must have an additive identity: ForAll[x] x + 0.0 = x If -0.0 + 0.0 is not -0.0, then 0.0 is not the additive identity. What is it in your system?
