Re: More on trits & tetrits... (long)
> Date: Thu, 22 Apr 2010 15:23:00 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: More on trits & tetrits... (long)
>
> On 2010-04-10 19:09:49 -0700, Dan Zuras Intervals wrote:
> > For the decoration property 'bounded' we will have:
> >
> > boundedFalse = {There exists x in xx such that f(x)
> > is infinite (rounds to infinity)}
> >
> > boundedTrue = {There exists x in xx such that f(x)
> > is finite (rounds to finite number)}
>
> This is not the same "bounded" property as the one that was considered
> (which was a level-1 definition, i.e. where f is a function on real
> numbers). For instance, let eps be a positive machine number such that
> 1/eps overflows. What we would like is to regard 1/[0,1] as unbounded
> and 1/[eps,1] as bounded. But with your definition, you would get
> { boundedFalse, boundedTrue } is both cases, which is much less
> interesting.
>
> > Thus, if one evaluates, for example exp() in single precision
> > on the interval [0,100] the answer will be
> > {[1,oo],{boundedFalse,boundedTrue}}.
> >
> > We do not know whether or not an actual pole was encountered.
>
> That's the problem.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
I know, Vincent.
Your way allows you to distinguish between those two
cases but the distinction lives in the decoration.
Thus, if xx = 1/[0,1] = {[1,oo],{boundedFalse}} &
yy = 1/[eps,1] = {[1,oo],{boundedTrue}} we can answer
questions like isContained(xx,yy) or isContained(yy,xx)
but the answer ALSO lives in the decoration.
This violates our principle that the computation part
of an answer should depend on the interval part of the
operands only & not the decoration. It also requires
a somewhat different definition of the 'bounded'
decoration itself.
The other way, the 'bounded' decoration is defined in
exactly the same way as any other decoration: one bit
tells you if there are points for which the decoration
is true & the other bit tells you if there are points
for which the decoration is false.
And the problem goes away because the answer to 1/[0,1]
& 1/[eps,1] are both {[1,oo],{boundedFalse,boundedTrue}]
& can no longer be distinguished.
Which is as it should be, IMHO.
As I explained in the accompanying text, this is because
overflow introduces a range error in the result that is
analogous to precision error we get when both the
following problems get the same answer
[1,1+eps] + [0,eps] = [1,1+2eps]
[1,1+eps] + [0,del] = [1,1+2eps]
because both (1+eps) + eps = (1+eps) + del = 1+2eps happen
to round up to the same number.
In essence, your definition is adding one bit to the range
just as decorating this problem with 'exact' or 'inexact'
would add one bit to the precision.
The fault lies not in our math but in our limited ability
to realize that math in the finite number of bits afforded
to us in any given floating-point datatype.
And the solution is the same in both cases: Go to a higher
precision & range & do the calculation again.
Sooner or later you will reach a precision (or range) wide
enough to properly represent your result & the ambiguity
will be gone.
That's the idea, anyway.
Dan