Take care to write different methods for what runs and what chooses. For example:
You can also get meta-level with the choice.
In the second option, the means and sd could be discrete and drawn from a set list (e.g. mean is one of {6,8,10,12,14} and st is one of {0.1,0.25,0.5,1,2}). The learner could then report (say) when the current conclusions fail cause the standard deviation gets too large.
A lot of the following methods require checks on some global working memory. How you code the working memory is up to you but some general principles apply:
Please do not read the following list of methods as "these are different methods". In practice, they blur into each other and real systems use a little of this and a little of that.
The following methods can all be elaborated, ad infinitum, with supposedly "better" features. Resist that urge. Ask yourself "is adding one more features to handle this special case really worth it"? Every new feature is one more potentially confusing thing to struggle with at modeling time. Remember, simplicity and uniformity are the most powerful modeling constructs.
Just wing that puppy. Go for it. Anyway you want (and just accept the fact that you will code up the same pattern of interaction, many times).
Declare that all "things" in your environment respond to methods:
The main loop of this program would be something like this:
Two problems with the above are:
Both the following tricks reduce the space in which we look for "match"ed things.
Every "thing" has a "when" stamp on when it should be executed. So, to schedule an event in the future, give it a "when" that is after "now:.
Turn the list of "things", into a sorted list of sets of things. Each set holds the "things" scheduled for the same "when". This list is sorted decreasing on "when" (so adding future events is a simple matter of pushing to the front of the list).
The main loop of this program would be something like this:
Define a set of global events such as rain, flood, fire, userSpeaks, etc.
Define an interrupt stack.
Turn the list of "things", into a hash table of sets of things. Each set holds the "things" triggered by a particlar even.
The main loop of this program is two processes. Process one recognizes events (from the outside world, internally generated events), Process two runs like this:
Note that Method 3b becomes Method 3a if, every time the clock ticks, that generates an interrupt.
Declare that all "things" in your environment respond to methods:
The main loop of this program would be something like this:
Problems : xxxx INCREASES runt imes
If the global search of method #2 is too slow, XXX divide into partso
Standard methods are onEntry, whileIn, onExit
Why just match select act
Petri nets
COlored petri nets