Forums

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.

> 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.

This introduces a default, I more than dislike that.

> 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 :)

>
> 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.

Again a default which I strongly object against ;)

>
> 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.

We are voting on a proposal which is incomplete. This does not mean
that we cannot resolve the issues easily. 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

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.

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