Can resets be deactivated in favour of another?

[kerimoyle]

I'm sure I'm missing something here ... Is there a way to turn off a reset? Or to select either/or from the list of active resets on a variable? I'm trying to figure out how more than one can be applied to the same variable using the looping in the rule examples doc.

Here's my example: https://cellml-specification-dev.readthedocs.io/en/i144_informative_3_11_resets/reference/formal_and_informative/specC11_interpretation_of_variable_resets.html in the "see more" blocks, particularly the second.

... but it seems that I'd need to have a collection of boolean-esque (eek!) variables as well as the resets in order to combine them as I'd expect?

eg, resetA_is_active and reset_B_is_active variables which are evaluated in the maths somewhere, and these are what the resets respond to, rather than the order attribute.

I know I've got it wrong somewhere, I just can't see where ...

[agarny]

From what I understand from your example:

• Reset A has an order value of 1 and reset B an order value of 2:
  • Reset A gets triggerered;
  • The position has changed, so we get to check resets again;
  • Reset A gets triggered again;
  • The position hasn't changed, so we exit the reset iteration.
• Reset A has an order value of 2 and reset B an order value of 1:
  • Reset B gets triggered;
  • The position hasn't changed, so we exit the reset iteration.

For me, that is it, no...?

[kerimoyle]

So the "order" isn't very often used as an order, it's more a priority? I was expecting them all to be evaluated in "order", rather than stopping if nothing changed. II guess in general you'd put the most important one at a low order value so that it always gets evaluated, rather than a higher one so that its effects are felt last?

[MichaelClerx]

Yup!

But to clarify the wording: it's the same issue as #316 again!

When you're trying to figure out which resets are active, order is the order in which you go through the resets for each (connected variable set of a) reset variable.

If you think of it a different way, and say "I've found 10 resets on variable X which could be active, I wonder which one wins", then yes the name "order" is might be strange (although it gives the order of priority). We had some debate about calling it priority or things like that, but "order" won.

However, if you say "I'm going to look at all the resets for variable X, and stop as soon as I find one that's active", then "order" gives the order you should consider them in, and the current ordering of points 1-5 makes sense.

[nickerso]

If nothing changes then no resets are able to be activated, right? so you have to stop at that point...right?

[MichaelClerx]

for resets on variable X in order:
  if test_variable = test_value
    return reset

[kerimoyle]

I guess the bit that was missing for me was the "until I find one that's active" part. My reading of the normative spec so far is that they're all evaluated, even if the previous one hasn't changed anything. If that was clear earlier then the issue in #316 is not as niggly to me. Ho hum. But maybe that's why it's here ... and is perhaps an argument for putting that algorithm into the normative spec next time?

[MichaelClerx]

I think you're right and we're missing the "until I find one that's active" part in the current spec!

[MichaelClerx]

Not sure about sticking the full algorithm in (yet). I've updated the doc a bit to show that it does rely on a bunch of conditions we don't specify in the spec, and we're generally leaving the interpretation of the maths to the user...

[kerimoyle]

I guess it's not just the finding an active one (which is kinda there from a combo of the points, even if not explicitly); it's the idea that if nothing changes then none of the remaining active resets are evaluated at all - that idea isn't anywhere in the normative spec, I don't think?

[MichaelClerx]

I kinda hope it's enough to say they constitute discontinuous mappings in the state space, and then the idea that your algorithm stops if the mapping is from a point x to that same point x is more a common sense implementation thing than anything else?

So the spec should be clear that you:

• evaluate the tests for a particular var set X in order of the "order" attribute
• stop searching (for X) when a test_value == test_variable
• designate that reset the only "active" one for X

The thing in the suggested algorithm where you stop checking resets at all if they no longer affect your current position is separate from that

[kerimoyle]

your algorithm stops if the mapping is from a point x to that same point x

Yep, that bit is fine.

But ... that's not quite what (in my head ...) is happening? See this comment:#317 (comment)

• Reset A has an order value of 1 and reset B an order value of 2:
  • Reset A gets triggerered;
  • The position has changed, so we get to check resets again;
  • Reset A gets triggered again;
  • The position hasn't changed, so we exit the reset iteration.

In this situation, reset B never has a chance to change the system, as the repeated application of A makes no difference, and it stops checking for other active resets down the order list? This bit I don't find clear from the spec at the moment, but perhaps it's because I also didn't get the "only" from your comment above either:

• evaluate the tests for a particular var set X in order of the "order" attribute
• stop searching (for X) when a test_value == test_variable
• designate that reset the only "active" one for X

[MichaelClerx]

In this situation, reset B never has a chance to change the system

Yup!

A is active, and after applying its change it's still active, so B never gets active while A is. That's the whole point of the "order" attribute. It specifies the order in which you check if they're active. Not the order in which multiple active resets are applied. There's only one active reset per X.