[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?