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

Re: Reasons (not) to vote Motion 27: NO



Arnold Neumaier wrote:
On 08/02/2011 07:35 PM, Nate Hayes wrote:
Arnold Neumaier wrote:
I mean, what is the purpose
of having all the formalism for a FTDIA if a user's program can no
longer be
validated by it as soon as they include a single intersection or union
operation?

Intersection and union are very common operations in interval programs
and
algorithms...

Motion 26 has a concept of intersection and union, hence supports all
such
calculations. But for safety reasons it requires that the result is
always
a bare interval -- since the decoration it should get (if any) must
depend
on the context.

Can you please give several real-world (Level 1) examples demonstrating
each different context?

I'm very skeptical of this statement.

Apparently there are not just a few different contexts;

It should not be difficult for you to provide at least, say, three or four
such examples, then.



at least finding correct definitions of these contexts would require extra
research.

My example from the decoration file last December was of this kind.

For those that might be trying to follow along, here is the link to what
Arnold refers to:
   http://grouper.ieee.org/groups/1788/email/msg03570.html
He is speaking of the example appended to the end of the e-mail entitled
   "Appendix 2: a detailed example for intersection"
(not the PDF which is also attached to that e-mail).

The example involves the program "fgood", defined as:

function f = fgood(x,y)
   f=(2x+2y)/(2x+y);
   f1=2-2/(2+y/x);
   f2=1+1/(1+2x/y);
   f = f intersect f1 intersect f2
end

In practice, fgood is simply trying to compute a tight range enclosure on f.
This is the reason for intersecting the ranges of f, f1, and f2. However, f1
and f2 are not equivalent expressions of f. Hence, they are undefined at
different points than f. For example, f1([0,0],[3,4]) is empty/undefined
even though f([0,0],[3,4]) is safe, so taking the intersection gives an
empty/undefined result for fgood([0,0],[3,4]).

Since the theory of decorated intersection being advocated by John and
Arnold at that point in time predicted fgood should be safe in this case, it
was evidence the theory is invalid: thankfully John has at last finally
removed those definitions for decorated intersection and union from the most
recent version of Motion 26, so it is no longer on the table (of that much I
am grateful).

Indeed, from a purely mathematical point of view and by all standards and
interpretations, fgood([0,0],[3,4]) *SHOULD* be empty/undefined. I believe
very strongly it will never be a good idea for P1788 or any standards body
to try and invent a decoration system that gives another interpretation, as
this surley will be violation of the "thou shall not lie" commandment.

However, we all know and understand, in practice, what Arnold is trying to
do in the fgood program: he's trying to employ (useful) programming tricks
to give tighter range enclosure on his function so his program will run
faster. So of course in this respect what he's trying to accomplish is
completely legitimate... I do it all the time in my own software.

The problem, therefore, is a bug in the fgood program, not the decoration
system. In particular, the expert programmer (Arnold in this case) was
thinking as he wrote the program:

   "Even though I am completely aware that f1 and f2 are not equivalent
expressions of f, I am intentionally going to take thier intersections in
order to obtain a tighter range enclosure of f, which is the function I
really care about."

But as noted, the purpose of the decoration system is to detect that f1 and
f2 are not equivalent expressions of f and that taking their intersections
may lead to empty/undefined results.

So the problem is: the intent of the programmer was never adequately
captured in the fgood program. (for those of you familliar with Stanley
Kubrik's "2001 Space Odessy," it is not dissimilar to the programming bug
that caused the HAL computer to go on a killing spree)

The bottom line its not reasonable to expect a decoration system designed to
report undefined results should give a "safe" result just because the
programmer had this in mind. The intent of the programmer needs to be
expressed excplicitly in the program code of the fgood program. For example
the decorations of f1 and f2 should be checked, and the respective
intersections should be taken only of these decorations are safe.



After your response with the counterexample, I tried to find a _general_
rule that allows to decide when such constructions are valid without a
separate analysis for each case, and didn't find any.

As noted above, you will NEVER find such a general rule because it should
never exist. The decorations should never lie, even if the programmer has a
bug in the software.


My conclusion (after discussing things with John Pryce, who originated the
proposal now realized in Motion 26) was that all more than trivial
instances require individual attention.

If there are not any further examples, the now I am really convinced that
Motion 27-A1 must be passed.

Nate