Re: proposed new definition of preemption

I like the new algorithm.

David, a simplification would be to take the (in general) lcca of the
transition's source and it's targets and *then* you can do the descendent
check (if either is a descenant of the other then you can't run the later
transition).  If you browse earlier emails you will see that was the
algorithm I proposed; it is faster than this one and would get any case
correct that this one would get correct.

But Jim and I talked about this to great length and we agree that because
the algorithms have identical results (exit set vs. arena check) then it
didn't matter and Jim liked the exit set definition more because he felt it
was closer to UML specs.  I don't care at all really as long as we move to
using actual graph topology to do the check.

I think you pointed this out but if you want things to work out visually in
terms of preemption then you also want to select transitions in reverse
child order on the state when you are checking them.  Really, for
transitions you want complete reverse document order and this would mean
that you could, with your eyes, walk from an activated atom *up* the
document and the transition selection process would consistently move *up*
the document toward the root.  Currently we sort of move up, then down,
then up, then down as you pointed out earlier.

I would be in favor of such a change (select and preempt in reverse
document order).

Chris




On Tue, Feb 26, 2013 at 6:39 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  David,****
>
> For your first point, using ‘transition order’ amounts to using document
> order of the _*states*_ that selected the transitions, not the
> transitions themselves.  I agree that may be clearer.  All we have to do
> with the existing definition is call enabledTransitions.toList(), which
> will sort  them in the order in which the items were added, which is the
> order of the selecting states.  (By the way, the definition I sent around
> is wrong, in that it doesn’t sort them in any order.)  ****
>
> ** **
>
> On your third point, I think that you are right that targeted transitions
> will conflict if one’s source state is a descendent of the other’s, but
> that is not the only condition under which they conflict.  Consider a
> parallel element P with children S1, S2, and put transitions in S1, S2 that
> both exit P and go to different remote states (i.e., ones that cannot be
> simultaneously active).  The transitions in S1, S2 conflict, but neither’s
> source state is a descendent of the other’s.  However, I agree that
> practical implementations will not want to compute exit sets.  ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* David Junger [mailto:tffy@free.fr]
> *Sent:* Tuesday, February 26, 2013 4:18 AM
> *To:* VBWG Public (www-voice@w3.org)
> *Subject:* Re: proposed new definition of preemption****
>
> ** **
>
> Le 25 feb 2013 à 16:53, Jim Barnett a écrit :****
>
> ** **
>
> First, I think we should preempt in transition order, not document order
> (i.e. a transition should be preempted by transitions that are selected
> before it, not witten before it). If we use document order, then we'll end
> up with <state>s and <transition>s mixed in complex states to achieve a
> precise result, very hard to read or visualize.****
>
> q****
>
>  3.       Is it a good idea to get rid of the word “preemption”?  (the
> selectTransitions functions have to be modified to call
> removeConflictingTransitions instead of filterPreempted, but the argument
> to the functions and the return values are the same.  hasIntersection() und
> union() are defined in the list of functions/procedures at the top of the
> algorithm)****
>
>  ** **
>
> I don't mind the word. I just hoped we could find an elegant solution that
> made it unnecessary.****
>
>
>
> ****
>
> 4.       Is there a better way to do this?****
>
> ** **
>
> It seems that targeted transitions will always conflict if one's source
> state is a descendant of the other's and that those cases are precisely the
> cases that trip the source state approach. Is that correct? I don't think
> that would be a "better" way to explain it in the spec but if it is
> equivalent then I like it better for my implementation (in which I don't
> want to compile exit sets in advance, for example).****
>
> ** **
>
>                                     David****
>



-- 
A foolish consistency is the hobgoblin of little minds - Emerson