When the user explicitly requests a one-shot perturbation, the float parameter specified for the alarm is discarded and the perturbation fires the first time it can. This is not what a "one shot perturbation with alarm" means.
When explicitly requesting to not repeat the perturbation, the internal translation does not edit the statement by adding the boolean component ([T]>0), instead just having a [true] token, as is seen above in the witness file; compare mod 0 and mod 1. Not repeating perturbation is the default; this leads to a situation where a user that explicitly requests a behavior that is default, does not get default behavior.
Moreover, the "guard" that is the boolean condition added ([T] > 0) does not get added if the statement already contained a boolean condition. Swapping:
%mod: alarm 1 do $ADD 1 A() ;
for
%mod: alarm 1 (|deadlock()| > 0) do $ADD 1 A() ;
Produces time traces where both A and B got added from the get-go; both perturbations now ignore the user-specified float parameter. The witness file will list the line as:
Relying on this "guard" is both opaque, and error prone; we should not rely on re-interpreting the user's input. I suggest we either have some syntax for a true one-shot perturbation, or remove this guard and habituate users to add the [T]>0 component throughout our models.
When the user explicitly requests a one-shot perturbation, the float parameter specified for the alarm is discarded and the perturbation fires the first time it can. This is not what a "one shot perturbation with alarm" means.
Take the following example model:
The time traces for the observables look like:
Note that agent B was added from the get-go, at what seems to be T=0, rather than at T=2, which is what the model specifies.
The run produces a witness file like:
When explicitly requesting to not repeat the perturbation, the internal translation does not edit the statement by adding the boolean component
([T]>0)
, instead just having a[true]
token, as is seen above in the witness file; compare mod 0 and mod 1. Not repeating perturbation is the default; this leads to a situation where a user that explicitly requests a behavior that is default, does not get default behavior.Moreover, the "guard" that is the boolean condition added
([T] > 0)
does not get added if the statement already contained a boolean condition. Swapping:for
Produces time traces where both A and B got added from the get-go; both perturbations now ignore the user-specified float parameter. The witness file will list the line as:
Relying on this "guard" is both opaque, and error prone; we should not rely on re-interpreting the user's input. I suggest we either have some syntax for a true one-shot perturbation, or remove this guard and habituate users to add the
[T]>0
component throughout our models.