Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Comments on decoration ill, intersection and union



Nate, John, Vincent, P1788
There seems to be agreement that decorations concern point functions. And that union and intersection have no corresponding point operation. But there seems to be agreement how to use them to define piecewise defined continuous functions.
So what do you think, if we offer this as an option
"An implementation may  define propagation of decorations (for
piecewise defined continuous functions) in the way that
intersection propagates the max and union propagates the  min" ?
That makes it more complicated and invokes the danger of misuse
but it may help to end this dead-ended discussion
Jürgen

Am 17.12.2012 15:41, schrieb Nathan T. Hayes:
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


--
o Prof. Dr. Juergen Wolff von Gudenberg, Lehrstuhl fuer Informatik II
    / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o         Tel.: +49 931 / 31 86602
  / \  Uni       E-Mail: wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 o   o Wuerzburg