Forums

* Stefan Hoops <shoops@vbi.vt.edu> [2010-06-25 18:20] writes:
> Hello Lucian,
>
> On Fri, 25 Jun 2010 17:50:34 +0100
> Lucian Smith <lpsmith@spod-central.org> wrote:
>
> > I think we're saying the same thing? The firing of the X's in indeed
> > undefined. Because they are undefined (but *some* order must be
> > chosen) any of my four examples are possibilities. In fact, there
> > are 20 possibilities, and all of them are legal (120, if you include
> > the possible permutations of the X's). The simulator may choose any
> > method it wants to choose between them--the specification leaves it
> > undefined.
>
> No we are not saying the same thing. It is not possible to mix
> undefined and ordered.

OK, I guess I disagree then. But I don't know what you are saying, in
that case. I think it is perfectly possible to mix undefined and ordered,
as long as the ordered end up in order.

> Undefined behavior as in L2V4 and L3 is not the
> same as a random order.

True.

> It may be the same order every time you simulate

True.

> or it may change from simulation to simulation,

True.

> it may even lead to stopping the simulation.

I don't think this is an acceptable reading of the specification, so this
bit I disagree with. I think that the *order* is undefined, not the fact
that the events are supposed to fire. The spec says:

"It is assumed that, although the precise time at which these events are
executed is not resolved beyond the given point in simulated time,
the order in which the events occur is resolved."

It does *not* say 'or you can stop the simulation'. All the events must
fire, in an order that is up to you.


> Again, we should avoid defining a resolution of a situation which
> should be avoided to begin with.

I actually completely disagree with this philosophy. We should either
define what happens (even if only to say 'it is up to you, and a modeller
cannot rely on any one thing happening', as we do now with simultaneous
events), or we should declare that it is actually illegal.

*Are* you suggesting that we make it illegal? That would, I argue, be a
significant change from the current specification. If you are not
suggesting that, but you are claiming that a particular simulator *may
not* decide to mix in undefined-priority events with defined-priority
events, I don't see on what basis you are making this claim. If you are
not making either claim, then I think you actually are agreeing with what
I am trying to say, though I'll grant that you may be disagreeing with
what I unintentionally communicated.

> If someone decides that the order of
> simultaneous events is important for the correct simulation of a model
> than they need to define the priority of all events which may occur
> simultaneously. If that is not done the outcome is undefined.

Yes, with the caveat that I believe it is only the order of the events
firing that is undefined, and not that the behavior of the simulator is
left completely undefined. In other words, if there is a simulation with
N simultaneously-firing events in it, I believe that there are N! possible
execution pathways available to the simulator, some or all of which may
'collapse' into equivalent final states. But options like not executing
any of the events, or stopping the simulator, or executing all event
assignments twice, are all illegal.

Here, I'll work through a possible execution pathway of a simulator.
Let's say that this simulator normally executes simultaneous events in the
order it finds them in the file. This is perfectly legal behavior. There
are six such events that it has on its list:

A, B, C, D, E, F.

Now, it looks at the priorities. It discovers that because A, D, and F
interact with each other, the modeler has given them explicit priorities.
Events B, C, and E all do not interact at all with each other or with any
other event in the model, so the priorities were left off of those.

Now, it turns out that the priority order of A, D, and F is that D has the
highest priority, then A, then F. The simulator must now permute its
chosen order such that D executes before A, which executes before F.
There are two possible legal event orders it could do without changing the
overall order of events very much:

B, C, D, A, E, F
or
B, C, D, E, A, F

Now, this order is 'mixing in' undefined-priority events with
defined-priority events, but its only decisions were made in order to put
D-A-F in that order. The rest was a side-effect of the 'undefined order'
aspect of the spec.

A different possibility would be that the algorithm it uses first pulls
out all events with priorities and only executes them after everything
else has fired. In this case, it ends up firing them:

B, C, E, D, A, F

Or maybe it pulls them out and executes them first:

D, A, F, B, C, E.


I would argue that these are all perfectly legal. I would also argue that
it fulfils your requirements that there are no defaults, and that it
doesn't rely on random behavior vs. undefined behavior, and that it could
execute these events in the same order every time it encountered them
(should it so choose).

I would also argue that becuse B, C, and E all do not interact with the
rest of the model in terms of events firing, there is no need to make this
model illegal, or to stop the simulation. (However, I am not arguing that
the simulator or SBML interpreter actually check to make sure they don't
interact that way--they should just trust the modeler.)


Once again, I've probably written too much, but I do agree that it's an
important distinction to make.

-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