Pool values are not notified on add-expression changes

[vrozen]

Pool values are not properly notified in the Evaluator's notifyFlow method in MSG_HAS_VAL messages. Instead of returning fixed point numbers with two digits the messages return integer values. getIntValue is called instead of getValue on NumberValExp dividing the result by 100, effectively wasting the two digits.

[vrozen]

Additionally, the message MSG_HAS_VAL is missing when a flow modifies pool instances that are used in the "add expression" part of a pool that is not the source or the target of the edge the flow results from no message is sent.

e.g.

pool q at 1 add r
pool r at 2
auto pool s at 3
t: r --> s

when s pulls a resource from r the new observable value of q is not notified.

[vrozen]

The first idea to fix this is to simply not divide by 100 and adapt all relevant code. The messages MSG_HAS_VAL will then return 100 times larger values, e.g. 100 instead of 1 and 123 instead of 1.
Perhaps MSG_ADD_VAL and MSG_SUB_VAL should also return results fixed point for uniformity.

[vrozen]

Additionally, MSG_HAS_VAL messages have to be sent for pool instances that refer to changed pool instances in their expression part because the 'observable value' is changing.

This is tricky because it requires analyzing dependencies (ideally beforehand), or alternatively generating MSG_HAS_VAL messages for all pool instances every step which also gives additional overhead.

[vrozen]

Another option is to allow polling of observable pool instance values, but that breaks the event-driven design.

[vrozen]

MSG_HAS_VAL, MSG_ADD_VAL and MSG_SUB_VAL each report singed fixed point numbers where the two least value digits are the remainder. From now on divide by 100 to get the integer part and modulo by 100 to get the remainder.

[vrozen]

The brute force notifications for each pool instance value were too slow for AdapTower so I did not commit those. For now, change notifications are only sent if a node instance is involved in a flow. The notification is not sent if its observable value changes because of a flow between two other node instances and its add-expression refers to it.

[vrozen]

Verified fixed fixed point numbers.
9bc1627

[vrozen]

Currently, expressions are evaluated on values that are valid in between steps. This means that changes during a step are not taken into account. This decision impacts the possible transitions and resulting resource amounts and shortages.

The plan is to let PoolNodeInstances observe other PoolNodeInstances based on their add-expressions. This enables notifying instance observers about changes to the observable pool instance values also when the actual value did not change.

[vrozen]

Verified fixed 506a341

[vrozen]

What would be necessary to allow the reevaluation of expressions during steps?

There are three values associated with pool node instances:

1. The actual value, valid in between a steps, a result of an applied transition. The value is used to determine how many resources are in a pool instance after a step, to inform the library context.
2. The old value, valid during steps, used to calculate shortages. The value is used to determine if resources can be removed from a pool node instance during a step.
3. The new value, valid during steps, used to calculate capacity. The value is used to determine if resources can be added to a pool node instance during a step.

Currently expressions are evaluated on the pre-step actual value of pool node instances. This may be counter-intuitive since 'during step events' neither affect the temporary values inside pools, nor the amount of resources flowing.

For both expressions on pools and edges, it might make sense to reevaluate expressions on the new value instead of the actual value. Interestingly, that may require only one line of code to change, but it completely changes the possible outcomes of transitions.