Re: Motion P1788/M0008.01_Exception_Handling: Discussion Period Begins.
John Pryce wrote:
BUT your 3.2 seems to contradict either this or Motion 3. You say
"[normally,] given ... interval X
X \union Empty = X
some applications may need
X \union Empty = Empty."
Here, the named constant Empty is a decorated-interval, so I shall call
it dEmpty to distinguish it from the bare-interval constant Empty
(which, by motion 3, must exist as a member of the set of bare-intervals).
It seems you haven't read our response to Dan Zuras's comments on
3.2 since you raise the same point again. This was answered there.
A2.
There is something strange about M8/2.4 that may be related to the
previous point. Namely it seems to be saying
(eqn5) xx op yy = ( <xx, All0> op <yy, All0> ).ivl for any
bare-intervals xx, yy;
and the wording has the appearance of thereby _defining_ xx op yy.
But then the definitions are circular since 2.2 defines operations on
decorated intervals in terms of those on bare ones, while 2.4 does the
reverse.
Sectuion 2 consists of specifications, not definitions, hence
circularity is irrelevant. (A specification just lists requirements.)
It has no effect for xx*yy but is nontivial for xx*Y or xx*d
B.
My next point is more of a software engineering one. Consider the
standard validated ODE solver application, where you have
- a vector function f: D \subseteq R^n -> R^n
- a box xx in R^n
and you want to check that
- f is defined and continuous on the whole of xx, and
- f maps xx into itself,
which proves that a fixed-point theorem can be applied.
With a "FLAG" approach it works very simply:
- Assume f has been coded up as a function, as this is the typical case.
- Evaluate the interval version ff of f:
yy = ff(xx) where xx, yy are interval vectors of length n
- If Vienna proposal's "possiblyUndefined" flag wasn't raised, then all
is OK.
No. Continuity must also be checked, and Boundedness.
Thus you need 3 flags.
But with decorated intervals:
- Evaluate the decorated-interval version F of f:
Y = F(X) where X, Y are decorated-interval vectors of length n
- Now you have to check each component Y[i] of Y.
If each "possiblyUndefined" field in Y[i].dec is un-set, 0<=i<n, then
all is OK.
This is more messy. What is really one bit of information has been
spread over the n components of a vector. In my view this indicates an
inherently poor design.
Once you want to do parallel computation, the picture changes completely.
Moreover, the part of the computation that needs to be done with a
decoration is in most applications only a fraction of the total
computation time; most of the computations can be done without
decorations.
In particular, this holds here. The test for accepting as step in the
ODE method only need a function evaluation; the subsequent improvement
step needs no decorations but must propagate a high order Taylor
expansion, or something related, and therefore dominates the computation.
C. the "huge SIMD calculation".
We have discussed this problem in this forum, but I would welcome a
statement from P1788's compiler and hardware specialists.
Statement of problem:
- I have a (fairly simple) function, say like
f(x0,x1) = log(cos(x0)+sin(x1/exp(x0))+sqr(x0/x1))
in Nate Hayes' recent "paving" example.
- I want to evaluate it "vectorised", component-wise on
an interval vector of length 1,000,000, say,
and record whether "possiblyUndefined" was raised,
individually for each component.
"Vectorised" means that each elementary operation in f is a vector
operation -- e.g. in Matlab this could be achieved by writing
f = @(x0,x1)( log( cos(x0) + sin(x1./exp(x0)) + sqr(x0./x1) ) );
and calling f with vectors x0 and x1.
In fact they are to be decorated-interval vectors of length 1,000,000,
and we assume vector elementary functions have been written that set the
"possiblyUndefined" trit component-wise.
Possible snags:
- A binary64 interval is 2*8=16 bytes long. When decorated it grows to
17 bytes with a 4 trit design (or 18 bytes with 8 trits).
- To achieve fast access the compiler probably likes to align each
element of the array on a 16-byte boundary, which implies padding it out
from 17 to 32 bytes long. Lots of wasted storage!
Send it in packages of 8 floats and the the trits in an extra 16bytes.
with no memory overhead at little cost for maninging the packing and
unpacking.
Arnold Neumaier