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