| Date: Sat, 02 Jul 2005 02:05:12 -0400
 | 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.

 |   thereby only regions which do not overlap compare < or >

So what is returned by comparisons of overlapped regions?

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

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

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

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

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

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

One must be careful with numerical properties.  If I understand your
system, adding -0.0 to 0.0 returns -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.

(/ (+ (* -5 0.0) (/ #i+1/0)))