new schema design

[slwu89]

@slibkind suggested the following updated schema:

Some of the key points were:

• "actual person" object which maps to the set of persons, vs. the "person at a time" object refers to a person at a particular time
• finitely presented, infinite

Scheduling updates:

• find the person(s) to update, and get their current "person at time" element. Add a new "person at time" element with the updated state. Set the "next" of their current "person at time" element to be the one just added.
• to implement the update, set the "actual person" 's current to be the "person at time" element that was added
• to "fast forward", set their "current" to the "next" of their current "current" and repeat until the next of their current is itself.

Any new schema must fulfill the following:

• some inheritance between simple Markov models and models with event scheduling
• the user builds models by processes and events
• events have an arbitrary number of event listeners, functions that are called with the persons experiencing the event when the delay ticks down to 0
• there is a way to specify which Obs/Attrs will have updates queued to them (dynamic) and which are static. The Ob called State is always dynamic.

Note from 2/18/22 meeting:

dynamic attrs are linked to Person at a time, static attrs are attached to actual person.

[slwu89]

This schema as described here may not work, when not all states/attributes are updated on every time step:

┌────────┬─────────┬──────┬─────────────┬────────────┐
│ Person │ current │ next │ statestatic │ attrstatic │
├────────┼─────────┼──────┼─────────────┼────────────┤
│      1 │       1 │    1 │           1 │          1 │
│      2 │       2 │    0 │           1 │          2 │
│      3 │       3 │    2 │           1 │          3 │
│      4 │       4 │    0 │           2 │          4 │
│      5 │       5 │    0 │           2 │          5 │
│      6 │       6 │    0 │           2 │          6 │
└────────┴─────────┴──────┴─────────────┴────────────┘
┌─────────┬───────────────┬──────────────────────┬─────────────────────┐
│ Current │ current_state │ current_statedynamic │ current_attrdynamic │
├─────────┼───────────────┼──────────────────────┼─────────────────────┤
│       1 │             1 │                    1 │                   7 │
│       2 │             2 │                    2 │                   8 │
│       3 │             3 │                    3 │                   9 │
│       4 │             1 │                    1 │                  10 │
│       5 │             2 │                    2 │                  11 │
│       6 │             3 │                    3 │                  12 │
└─────────┴───────────────┴──────────────────────┴─────────────────────┘
┌──────┬────────────┬───────────────────┬──────────────────┐
│ Next │ next_state │ next_statedynamic │ next_attrdynamic │
├──────┼────────────┼───────────────────┼──────────────────┤
│    1 │          3 │                 0 │  140506839372384 │
│    2 │          1 │                 0 │                1 │
└──────┴────────────┴───────────────────┴──────────────────┘
┌───────┬────────────┐
│ State │ statelabel │
├───────┼────────────┤
│     1 │          S │
│     2 │          I │
│     3 │          R │
└───────┴────────────┘

In this case only the Ob "State" should be updated but because the "Next" object creates a single table to all updates, by definition the other objects/attributes are listed in the updates. Because not every object or attribute will be updated each time step, this is undesirable (also in this example the unset statedynamic and attrdynamic objects will be set to unintended values).

What we need is for each dynamic object or attribute to have its own update table. This is how individual does it.

One way to do this is to have this kind of a relation between each state or attribute which is dynamic.