state of dutch politics machine

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: {possible inputs/new_state} {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, the first list argument is not in good practice enough.

Lets see how we can add a new transition

get_options koekoek

{} {0} {unknown input: define the transition first for koekoek and extend transition function input domain}

set next_sodp(worse,koekoek) {the worst}
get_options koekoek

{} {0} {unknown input: define the transition first for koekoek and extend transition function input domain}

set sodp $next_sodp($sodp,pvda)

worse

get_options koekoek

{the worst} {-1} {validation is based on improvement given positive number}

It would be nicer of the query possibility to list that we have a koekoek transition, except it will only work from the worse than bad state to arrive at the worst state. We could suggest that too, as query response.

Now lets extend the state domain with another few states:

set dsodp "protestant $dsodp catholic"
set next_sodp(the\ worst,Luther) protestant
set sodp $next_sodp($sodp,koekoek)

the worst

get_options Luther

{protestant} {4} {validation is based on improvement given positive number}

After adding a element to the domain, we could want to detect there is no state transition leading to that new possible state. Also we didn't yet define multiple transitions. And of course when we allow run time additions of domain elements and transitions, the new state computations should contain double checks, too.

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.

Lars H - How about Tom Lehrer's old suggestion for the official song for the US army: It Makes A Fellow Proud To Be A Soldier [L1 ]?

Something like:

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

(Quuuiiieeet !!!!)

(Maybe not a training drill song, but still on a similar theme: If You're Happy And You Know It Bomb Iraq [L2 ]. Also available as singalong at [L3 ].)

TV I did a song using a simulated guitar I wrote my own software for about the assasinator of a dutch politician a year ago [L4 ]