Intersection example (was Re: Motion 26: NO)
Arnold Neumaier wrote:
-- Not giving any specification for how intersection and union handle
decorations means users will invent their own (probably wrong) rules,
i.e.,
what is the standard? Examples were given that show how incorrect
handling
of decorations with intersection or union can lead to catastrophic
failures,
so this is not something that should be left up to users.
I had given an example where Motion 27 gives erroneous results for
decorated intersections:
The expression f(x)= x/((x+1) intersect x^2) is undefined for any x in
[1,3], but Definition 7 claims a safe answer for f([1,3]).
Arnold, this is not any example of erroneous results.
First of all:
( [1,3] + 1 ) intersect [1,3]^2
= [2,4] intersect [1,9]
= [2,4]
and [1,3] / [2,4] = [1/4,3/2]. The function is not undefined anywhere on
[1,3].
I'm assuming instead you meant f(x) = u(x) intersect v(x) where
u(x) = x/(x+1)
v(x) = x^2.
In this case u([1,3]) = [1/4,3/2] and v([1,3]) = [1,9]. The intersection of
the true ranges of u([1,3]) and v([1,3]) is empty; but even in this case the
decoration must be safe since u([1,3]) and v([1,3]) are continuous. The
nonempty intersection caused by overestimation is safe for the same reasons.
As I've noted several times before, giving another semantics for the
intersection operation leads to catastophic failures in certain algorithms,
like those depicted in the PDF attached to:
http://grouper.ieee.org/groups/1788/email/msg03570.html
It is far better to have no decorations at all for union and intersection
than to have decorations based on a logically faulty basis.
You have not demonstrated a faulty basis in providing the decorations; but
IMHO give another example why they are necessary.
Nate