Forums

* shoops <shoops@vbi.vt.edu> [2010-06-25 03:03] writes:
> Hello Chris,
>
> On Thu, 24 Jun 2010 18:02:03 -0600
> "Chris J. Myers" <myers@ece.utah.edu> wrote:
>
> > It is the execution phase where it is evaluated. Also, newly
> > created events are the same as pending events. They must have a
> > higher priority than any other events pending to fire at this time
> > point to fire.
> >
>
> This is what I assumed but that must be stated clearly.

This is indeed the intention, and should it be voted in, the specification
will indeed need to say this.


> > Another solution is to fall back on the old spec which say
> > their firing order is undefined. This solution is the cleanest
> > perhaps as there is no need for a default and tools that don't
> > support priority expressions can fall back on the old spec. If you
> > want to define behavior for your simultaneous events, you must add
> > priority expressions to all your events.
>
> This is where I was headed :)

This is certainly what I was thinking, too. No priority = undefined, and
you can have it execute in whatever order you want--random, alphabetical,
order in the file, whatever. You could mix them in with events with
priorities, or not, as you saw fit.

> I actually think that we
> have done it more or less as it seems we can agree on the following:
>
> 1) All simultaneously executed events have the priority object
> As specified in the proposal/vote
>
> 2) None of the simultaneously executed events has the priority object
> Not defined as in L2V4 and L3 currently
>
> 3) Some simultaneously executed events have the priority object and
> some not.
> Not defined as in L2V4 and L3 currently

Yes, except that in #3, those events with priorities must execute in
priority order. It's only the events without priorities that may execute
in any order.

> It is entirely possible that even for the case of 'not defined'
> simulataneous execution will lead to a welldefined solution. This is
> the case if simulataneous events do not have conflicting assignments.
> In that case all assignments could be executed as one block. If we want
> this behavior we should add it to the specs.

This, however, I slightly disagree with, since even non-conflicting
assignments could in turn cause other events to fire that would not
trigger if they were all executed before any triggers were again checked.
I believe that the current spec should be interpreted as declaring that
simultaneous events execute sequentially in an undefined order, with
checks for event triggers between each event's execution, and not 'all at
once' in an undefined order, with only a single event trigger check at the
end of all executions.

This, however, is an interpretation of the current spec, and should not
affect this new proposal.

-Lucian
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu