Version 3 of state of dutch politics machine

Updated 2003-04-15 00:56:02

page idea Theo Verelst (Apr 14 03)

First we define the domain of the initial state variable State-Of-Dutch-Politics, abbreviated sodp domain, and initialize the state variable:

 set dsodp {better bad worse {the worst}}
 set sodp bad

As a very simplistic choice of input variable, we take it to reflect the election winner, assuming there is one, and that this quantizeable and qualifiable, and for now define the finite state machine input domain, and a few quasi random transitions:

 set electd {cu vvd cp cda d66 pvda grl}
 set next_sodp(bad,d66) better
 set next_sodp(bad,pvda) worse
 set next_sodp(bad,cp) undefined

The last definition is a final state, it has to be defined in the domain of the state transition functions, but it is not defined in the domain of that function, so the machine cannot continue ticking from there on according to its definition.

To make sure we get a good result, or to make sure we only 'try' valid options without working the whole machinery, and without a catch construct being needed and to stay within mathematically and programmingwise acceptable and neat ways, we could introduce a query function, which returns the possible state transitions from a certain state, maybe with some weighing of options:

 # returns tree entry list: new_state(s) validation message
 proc get_options {{try {}} } {
    global dsodp sodp next_sodp electd 
    if {[lsearch $dsodp $sodp] <0} {return "{} {} {you don\'t start from a valid state}" }
    if {$try == {}} {set rr {}; foreach i [array names next_sodp $sodp,*] {lappend rr [lindex [split $i ,] end]}; return "{$rr} {?} {possible inputs which satisfy domain of transition function given the current state}" }
    if {[array get next_sodp $sodp,$try] == {}} { return "{} {0} {unknown input: define the transition first for $try and extend transition function input domain}" }
    if {[lsearch $dsodp $next_sodp($sodp,$try)] <0} { return "{$next_sodp($sodp,$try)} {?} {the new state would not be in the domain of the possible starting states for a new transition}" }
    return "{$next_sodp($sodp,$try)} {[expr [lsearch $dsodp $sodp] - [lsearch $dsodp $next_sodp($sodp,$try)] ]} {validation is based on improvement given positive number}"

 }

now we can call the procedure starting from a certain current state of dutch politics to get important information on the possible next state:

    set sodp bad
    get_options
 {cp pvda d66} {?} {possible inputs which satisfy domain of transition function given the current state}

we can try to select a new state before we actualy call for an actual transition:

    get_options pvda
 {worse} {-1} {validation is based on improvement given positive number}
    get_options d66
 {better} {1} {validation is based on improvement given positive number}
    get_options try_something_else
 {} {0} {unknown input: define the transition first for try_something_else and extend transition function input domain}
    get_options cp

{undefined} {?} {the new state would not be in the domain of the possible starting states for a new transition}

Surely, we must neatly define our labels, and keep accurate record of them.

---

For all university student wannabees or exes or whatever in between, the following exercise would seem appropriate:

Estimate the order of the growth rate of the various variables and functions size or of the number of possibilities they span. For instance, suppose we take into account all possible election results as unordered combinations of exactly two parties, how many new states can arise, or: how big would the transition table need to be when the number of states remains the same and one mapping function to an intermedeate valuation is allowed?

---

I'm trying to think of something along the lines of an american army training drill song, but nothing good enough crossed my mind yet.

Something like:

  saddam's bagdad's mighty strong,
  nothing a few tomahawks couldn'd solve
  hugh habba habba habba,

(Quuuiiieeet !!!!)