> In SRFI-70, both +0 and -0 would be within the neighborhood around 0.0
> represented by 0.0.
- I've just been assuming that it may be preferable to preserve the
convention non-signed values are positive 0.0 == +0.0, 1.0 == +1.0, etc.
and negative values require a minus -0.0, -1.0, etc.
and inexact values contain a radix point 0.0, 1.0, etc.
and exact values don't 0, 1, 2, etc.
where the relative ordering and reciprocal and negative projection
of inexact values about ~0.0 and ~inf.0 would therefore look like:
/ ~inf.0 \ or equivalently: / #i~/0 \
/ | \ / | \
-inf.0 | inf.0 #i-/0 | #i/0
------+------- (reciprocal projection axis) ------+------
-0.0 | 0.0 #i-0 | #i0
\ | / \ | /
\ ~0.0 / \ #i~0 /
| |
0 #e0
(negative projection axis) (negative projection axis)
> Several difficulties with -0.0 not equal to 0.0 were shown in
> <http://srfi.schemers.org/srfi-73/mail-archive/msg00002.html>
> #i~0 adds further complications with comparisons:
>
> Is #i~0 less than, equal to, or greater than 0.0?
- Yes, therefore it seems both reasonable and useful to define:
(= -0.0 ~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
thereby only regions which do not overlap compare < or >
(<= -0.0 0 0.0) => #t
(>= 0.0 0 -0.0) => #t
thereby only 0 is (and (<= x 0.0) (>= x -0.0))
and only ~0 is (and (= x 0) (not (<= x 0.0)) (not (>= x -0.0)))
> Is #i~0 an integer?
- not if integers are considered exact.
> | > (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 a 12.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?
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).
[as after all, its a consequence of an inexact value representation,
just as (* #e1/3 3) may not produce a value of an exact 1, it
doesn't mean that it shouldn't be defined to be so, although the
result will be constrained by the precision of the representation.]
> | and as noted #i~1/0 may be though of as NAN, which is what IEEE-754
> | considers both it and 1/0 to be, so it's actually more consistent
> | than it may first appear.
>
> In IEEE-754 the result of 1.0/0.0 is positive infinity, +inf, not NAN.
- yes agreed, 0.0 == +0.0, therefore (/ 0.0) => inf.0, and (/ inf.0) => 0.0
but the statement was about #i~1/0 == (/ ~0.0) == ~inf.0 being like NAN.
> | > 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?
(although may not be as may be computed and/or represented within
a particular floating point implementation. as it should not be
the basis upon which to define the value of a function, as it's
the responsibility of an inexact implementation to as closely
approximate the correct value as best it reasonably can. which
doesn't change the fact that (tan pi/2) == ~inf.0, as should
result in an implementation capable of representing pi/2 with
sufficient precision to yield correspondingly precise results.)
> | and correspondingly (/ (tan pi/2)) => ~0 thereby all functions
> | may be thought of as being evaluated about simultaneously
> | converging points about their specified values
> | (f x y) == (f (+ x ~0.0) (+ y ~0.0)).
> | including (tan (+ pi/2 ~0.0))
>
> ~0.0 will be much smaller in magnitude than the LSB of the
> floating-point neighborhood containing pi/2. So the ~0.0 will just
> disappear when added to pi/2.
- again, this is a function of the precision of a particular
implementation's precision. (where the example was meant as an
abstraction, as the values -0.0 and 0.0 should not be accumulating
values, therefore yes in all cases (+ x 0.0) == x, but this has
nothing to do with what a particular inexact implementation is
capable of sufficiency representing or computing to reproduce
itself mechanically.
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.
> | 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.)
> | > | (abs ~inf.0) => +inf.0
> | > | (- (abs ~inf.0) => -inf.0
> | > | (abs ~0.0) => +0.0
> | > | (- (abs ~0.0)) -0.0
> | > |
> | > | (+ +0.0 -0.0) => ~0.0
> | > |
> | > | Where I believe it's reasonable to redefine the use of IEEE's NAN
> | > | values to encode these values, as arguably ~inf.0 may be thought
> | > | of as being NAN, and ~0.0 as being 1/NAN (leaving 0.0 == +0.0)
> | >
> | > For some expressions returning #i0/0, no number has any more claim to
> | > correctness than any other. For example any number x satisfies:
> | >
> | > 0*x=0.
> | >
> | > So #i0/0 could be any number (if we forget that division by zero is
> | > undefined). The reciprocal of this #i0/0 potentially maps to any
> | > number; which is represented by #i0/0.
> |
> | - As I presently believe it's important to adopt a uniform convention
> | which dictates how multi-variable values are evaluated, using the
> | the convention above, which I believe to be most generally useful:
> | then #i0/0 == 1, if one considers the signs of the converging difference
> | in magnitude of a multi-variable function to uniform albeit ambiguous,
> | thereby, the ratio of: 0/0 == 1 == 100%, thereby 100% of 0/0 == 0, not
> | some useless error.
>
> It can be useful to have an inexact number which stands in for a
> numerical result about which there is no information. #i0/0 is that
> number in SRFI-70. As SRFI-70 states: "0/0 can be considered an error
> waiting to happen."
- I don't strongly disagree.
> The 0/0 you are writing about is quite different.
- again my apologies, I was being sloppy writing 0/0, when I meant 0.0/0.0.
> | or 0/0 == ~1, if the their signs are not necessarily considered
> | uniform. which is likely most technically correct, and yields:
> | ~100% of 0/0 == ~0, but I know you're not too enthusiastic about
> | ~1 which I avoided earlier, by only introducing ~0 which happens
> | to represent a pair of ordered values with no intervening
> | potential ordering ambiguity to speak of.
