Section 2 - Modules, Time Levels and Lists
Go to the Experiment pane in the model instance browser. Enter and evaluate the following:
and
= ?list [6 3 4 9]\
= ?list [?a ?b ?c ?d]
This results in each of the variables ?a, ?b, ?c and ?d are bound to the corresponding items in each list position. In this format the length of lists must be the same for them to be matched with "=". If they are of different lengths you will be no bindings. The contents of SDML lists can be almost anything (names, other lists, strings etc...).
Enter and evaluate:
and
= ?list [6 3 4 9]\
= ?list [?a ?b ?c]
and you will find there are no bindings.
Frequently we are only interested in the first few items of a list and we do not know how long the list will be. Then we use the "|" notation in lists. The bit before the "|" must exactly match, item for item, as in the first list example above but the bit after can match the rest of the list, however long.
Enter and evaluate:
and
= ?list [6 3 4 9]\
= ?list [?a ?b | ?rest ]
Here ?a and ?b are specifically matched but ?rest is matched with whatever is left (in the form of a list).
?a <=> 6
?b <=> 3
?rest <=> [4 9]
What do you think the ?rest variable will be matched with if you evaluated this?
and
= ?list [6 3 4 9]\
= ?list [?a ?b ?c ?d | ?rest ]
What would happen with this?
and
= ?list [6 3 4 9]\
= ?list [ ?a ?b ?c ?d ?e | ?rest ]
This list notation is very convenient and can be used to shorten rules considerably. SDML comes with a range of primitives specifically to handle lists (look in the lists category in the Definitions page).
Now we are ready to continue with our model. Go back to the content rulebase and select the queue update category. Create a rule called next consumer with antecedent:
queue [?nextCons | ?rest]
and consequent:
currentConsumer ?nextCons
This will match the next consumer (to purchase) with the first in the current queue.
Now write another rule called update queue to change the queue now the first customer is being served. The new queue will be composed of the rest of the queue at the last iteration (if there was one). It will thus have antecedent:
last iteration (queue [?nextCons | ?rest])
and consequent:
queue ?rest
At this point it would be nice to try the simulation. But Beware! Before we can try the simulation so far we need a rule to assert when the final iteration will be.
Under the finishing category in the Content rulebase create a new rule called final iteration with antecedent:
queue [?lastCons]
and consequent:
final iteration
The last iteration will be when there is only the one customer in the queue, because the will make their purchase this iteration.
Now bring to the front (or re-open) a rule firing transcript and restart the simulation. You can halt the simulation using the Control+C key combination when you have got the hang of what is happening.
You should see that for each week the rules next consumer and queue update are fired once an iteration and that there is one iteration for each consumer.
Generated with CERN WebMaker