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.
| Date: Mon, 04 Jul 2005 13:49:25 -0400 | From: 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? 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?