RE: Comments on decoration ill, intersection and union

["Nathan T. Hayes" <nh@xxxxxxxxxxxxxxxxx>]

John Pryce wrote:
> Maybe my remarks aren't relevant to Nate's specific query, but Vincent
puts his finger
> on my main uneasiness with decorations on the result of set operations. I
copy, below,
> one of the examples from the decorations text currently up for vote. This
is a VERY
> common paradigm where set operations are used. A function f(x) is defined
piecewise,
> by different formulae in different regions. To evaluate f over a box xx,
> - Cut the box in pieces xx_i, by intersecting with each region.
> - Evaluate f over each piece to get a piece yy_i of result.
> - Take the union (convexHull) of the yy_i to get final yy.
...
> In the example below it's only the *programmer's knowledge* that f(x)
actually is
> continuous at the region interfaces (here, x=-2 and x=2), that makes it
correct to
> propagate decorations by the simple statement
>   dy = dx
> 
> Suppose f had been defined so the pieces are continuous, but there is a
jump at x=-2
> or x=2 or both. Then to decorate it correctly you need to consider whether
input
> interval xx has points in each of the 3 regions, similarly to decorating
the "sign"
> function.
> 
> Nate may prefer a different interpretation; but like Vincent, I would like
decorations to
> give information about the continuity, etc., of an underlying point
function. All the
> theoretical interval models under consideration (set-based, Kaucher or
other) are
> *inherently* unable to do this automatically for piecewise functions. The
only way to
> achieve it is by individual inspection -- as with care homes.

I agree with this overall assessment of the situation. I would even go
further to say that no matter what *decoration model* this cannot be
accomplished automatically for non-continuous piecewise functions.

As an example, to decorate the sign function with the either decoration
system requires a user to write code something like this (assume for the
moment X=[a,b] is nonempty):

	Sign([a,b]) :=	([1,1],dac)	if a >= 1
				([0,0],dac)	if b < 0
				([0,1],trv)	otherwise

However, this is not an argument against decorating set operations, IMO.
From a set-theoretic perspective, if one has two DAC interval ranges of a
point function, for example, the nonempty intersection of those ranges is
DAC, even though the intersection operation is not a point function. The
user code above is consistent with this rule, and actually explains why the
user had to write the 3-way conditional statement.

John, as you mention above, piecewise functions are very common. In the case
the piecewise function is also continuous (as in the case of b-spline
polynomials and many other class of common and important functions), the
decorations can/should be automatically computed with decorated set
operations. In my view, there's no reason such calculations should suffer
significant performance penalties because the P1788 standard would prohibit
an interval processor, for example, from calculating the decorations in this
scenario as fast as decorations for arithmetic operations.

So, all else being equal, I think decorated set operations allow for faster
implementations. If an interval processor is available and the function is
continuous, the decorations for set operations can be computed at the same
speed as for arithmetic operations by the interval processor, without
needing to eat clock cycles and registers on the ALU/FPU.

Nate