Forums

Oops. Hit send prematurely.

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.

The last point you mention about what to do if no priority expression
is given is more subtle. At the hackathon, we agreed that
simultaneously enabled events should be fired in a random order. How
we achieve this when all events don't have priorities can safely be
arbitrary. Obviously if all have priorities we are also okay. The
problem is when there is a mixture. One solution would be to assign
some sort of default priortity like a uniform random variable.
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.

One other approach is to say all events with no priority have equal
priority which is either expressly larger or smaller than those with
priority. By the way, this is not all that different than giving all
events the same constant priority as this should result in a random
choice.

Anyway, I think if we go with the timing of events without priorities
is arbitrary, i don't see why we cannot vote. The vote at this point
is whether this is a good thing to add.

Chris

Sent from my iPod

On Jun 24, 2010, at 5:10 PM, shoops <shoops@vbi.vt.edu> wrote:

> Hello All,
>
> I have some trouble with this proposal/vote. The term 'goes first' is
> ambiguous. An event has 3 distinct phase:
>
> 1) Firing: Trigger changes from false to true.
> If useValueFromTriggerTime is true calculate the assignment values
>
> 2) Optional delay
>
> 3) Execution:
> If useValueFromTriggerTime is false calculate the assignment values
> Assign calculated values to targets.
>
> The priority can effect different phases. The final result will depend
> on it. For a single priority object to resolve simultaneity I think we
> need to place its effect on the execution phase as simultaneity may be
> not a result of firing by itself but a combination of firing and
> delay.
>
> Additionally, since the priority object is optional we need to specify
> the behavior for 3 different situations:
>
> 1) All simultaneously executed events have the priority object
> 2) None of the simultaneously executed events has the priority object
> 3) Some simultaneously executed events have the priority object and
> some not.
>
> Another point, which is open, is what has to be done with cascading
> events, i.e., an event with a higher priority triggers further events
> without delay. Are these cascading events processed before the
> remaining events or are they added to the priority queue.
>
> Before these points are resolved and specified I think voting on
> this is
> premature.
>
> Thanks,
> Stefan
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax: (540) 231-2606
> Email: shoops@vbi.vt.edu
> ____________________________________________________________
> 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
____________________________________________________________
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