Added TORCS SCR interface.

The SCR is a bot for TORCS used for external control.
http://sourceforge.net/projects/cig/
Renamed type synonyms in Golog.Interpreter.

We now have only two type synonyms, Conf and ConfIO, both with a payload
parameter.
Also renamed treeIO to treeNDIO.

Before, we had Conf, ConfND, ConfDT, ConfIO (which actually should have
been ConfNDIO) and ConfDTIO, only Conf of which had a payload parameter.
However, ConfND, ConfDT, ConfIO and ConfDTIO were only used once each:
in the treeND, treeDT, treeIO, treeDTIO functions.
Introducing a type synonym which is used only once seems mindless.

The sync function, however, had an ugly signature because it used the
general Conf type synonym and thus had to explicitly mention the SyncIO
payload parameter. Now the new SyncIO fits this job.

The new type synonyms also make searching easier. E.g., if someone wants
to check which functions to use to obtain something that can be handed
over to sync, she just needs to search for ConfIO as used in sync's
signature.
Started a SitCalc SCR driver.
Fixed a few bugs in TORCS interface.
Fixed bug in TORCS trackTime computation.

The trackTime function converts virtual laser beam lengths into temporal
values. The computation was broken.
Golog.Interpreter: renamed function den to ast.

I think it's an abstract syntax tree which is returned by this function.
The old name was supposed to stand for `denotational', but I don't know
whether this makes sense.
SCR: fixed angles, typo in steering command

The manual is wrong about the `steering' command, it's actually `steer'.
The angles for the track laser sensors were wrong (missing minus signs).
Golog.Interpreter: IO generalized to any Monad m

The modification was minor, just had to add a parameter m to ConfIO and
SyncIO and the IOBAT typeclass. The latter requires use of the
MultiParamTypeClasses extension.

I've left the naming ConfIO, SyncIO etc., because this conveys the idea
best. I don't think a use-case of a Maybe or Either monad makes much
sense. I guess the main alternatives to the IO monad are ST and STM
monads.
TORCS: mostly documentation

Also extended the Golog.Util.HistBAT class a little bit.
TORCS: continued SimpleDriver architecture.

Still untested.
TORCS: continued BATs
Golog.Interpreter: fixed sync loop in test actions.

Assume a configuration c' was reached from a configuration c by
executing a successful test action.
The old exec function just copies the configuration c to c'. This
particularly copies the payload. (This was something we had thought
about earlier, because for that reason we couldn't increase d to d+1 in
the DT interpreter.) The IO interpreters have as payload an action which
returns a configuration, and in the described scenario this
configuration proceeds once again with the test action, because it's
just a copy of c!

This is clearly unwanted behavior as it leads to loops.

Unfortunately the code doesn't get nicer due to the additional functions
that update the payload in case a test action was executed.

A reasonable consideration seems to be to drop test actions. They can be
simulated by a primitive action `Test (\s -> ...)' whose precondition
evaluates the formula.
To avoid cluttering the situation term, the do_ function could ignore
it: do_ (Test _) s = s.

Interestingly the Test construct only occurs in two places in the whole
Golog.Interpreter module: the data definition of Atom and the case of
the exec function.
Golog.Interpreter: dropped test actions.

As explained in commit 9db2c82f24e9f076e9adbe8b94df75e0fe4d1280
("Golog.Interpreter: fixed sync loop in test actions."), test actions
can be fully emulated using primitive actions in our framework. Here's a
quote from the mentioned commit's message:

(Begin of quote.)

A reasonable consideration seems to be to drop test actions. They can be
simulated by a primitive action `Test (\s -> ...)' whose precondition
evaluates the formula.
To avoid cluttering the situation term, the do_ function could ignore
it: do_ (Test _) s = s.

Interestingly the Test construct only occurs in two places in the whole
Golog.Interpreter module: the data definition of Atom and the case of
the exec function.

(End of quote.)

Now there is a class TestAction in Golog.Macro which allows us to keep
macros like test, ifThenElse, while, etc.
TORCS: continued with simple driver.
Golog.Interpreter: fixed wrong resolution of nondeterminism.

When a program p* where p has a negative reward is executed, the best
execution is to stop immediately, i.e., the program should be final in
treeDT.

The program leads to the tree
  Val S0
    Alt
      Empty
      Val (Do p S0)
        Alt
        ...

The old resolve function went from the root Val node to the Alt node and
there compared all the alternatives. The chooseDT function tells the
best function to treat Empty same as Val Flop nodes, i.e., failed
execution, and returns the worst possible reward (-1/0,minBound).

The new resolve function hands over the reward of the Val S0 node, more
generally, the latest Val node's reward, to the resolution function.
Thus when best encounters an Empty node, it can return this reward.
TORCS: working on simulation of CarState.

Fixed a few mistakes in the simulation of the state for offline
execution.

We want to use treeDTIO, but for that we need a reasonable reward
function. For example, to steer the car to the middle, the reward should
take into account the difference between the current trackPos and the
goal trackPos.

For that we need to be able to predict the effect of steering.
That's a problem still to be solved. Learning?
TORCS: learned steering/accel/brake influence.

Wrote a Python script that uses scikit-learn to from our examples.
The examples were recorded from a berniw car driving a bunch of
tracks. There are two datasets, one for training and one for validation.

Used SVR for learning. Reason: SVR was the first regression method I
found in the scikit-learn documentation.

The SVR prediction (at least in scikit-learn) is quite slow. For that
reason we generate lookup-tables. This also is an easy solution to bring
the scikit-learn results from Python to Haskell. More precisely, the
Python script generates simple C code which is interfaced by the module
TORCS.LUT.

The C code generated by the Python script is actually ugly. It would be
better it generated a large array literal instead of the initialization
code. For now I converted the code by hand (thanks to vim).
TORCS: ml.py generates LUT as a single array literal.

Main advantage is much faster compilation by GHC (or is it GCC?).
Golog.Interpreter: reward is now associated type of DTBAT class.

The (Reward, Depth) tuple is now everywhere replaced by a type which is
associated type of the DTBAT class.

Reason: Since there are no tests actions anymore in the interpreter
(they can be simulated by a primitive action (Test f) with a function
f :: Sit a -> Bool and definitions
  do_ (Test _) s = s
  poss (Test f) = f s
in the BAT typeclass), counting the depth independently doesn't make any
sense anymore anyway. (In fact with the reward outsourced to the DTBAT
instance, the user can avoid incrementing the depth for test actions
again!)
Restricting the reward to a Double value isn't very nice either.

Alternatively we could have used MultiParamTypeClasses.

The change also led to some nice simplifications in the code (I think
they would have been possible with the old model, too, but I'm not sure
right now):
 * treeDT just composes treeND and resolveDT
 * treeDTIO just composes treeNDIO and resolveDT and uses fmap
   to also apply resolveDT to all sync-actions
 * resolveDT is a new function which simply hands over chooseDT to
   resolve; the old chooseDT is now a sub-function of resolveDT.

The code is still untested; all DTBATs and some more code needs to be
adapted to compile.
Also a unit test should test that treeDTIO works correctly.
Refactored all BATs to use associated type Reward. Plus unit tests.

Successfully tested the code Golog.Interpreter modifications
from the previous commit 7edc66fad04000e99d2b1e5f2516f277ff8554a9.