responsibility reorganization code

lookahead

• lookahead Store => state
• lookahead class => functionality (uses Store)

mapper

• Mapper:
  • cleanup
  • remove functionality from membershipOracle/equivOracles and make separate class of run methods which use statevarMapper and abstractionMapper => later change into pipeline
• statevarMapper
• abstractionMapper

counterexample analysis

• CounterExample class -> stores counterexample, and does reduction
• CounterexampleAnalysis class : third phase after learning(1th) and testing (2nd)

fresh output value store

similar as for inputs

statistics

• make phases generic so that we can easily add more
• in code we have statistics.switchToPhase(statistics.enumPhase) and statistics.incInput() for current phase! and maybe statistics.pauseCount() -> to temporarely disable counting when execting some extra debug code...
• make printing report more generic with generic phases ( take order of enum )

config

• default config in file
• allow multiple config files (later overrule earlier)
• apply multiple config files to define a config for the whole batch, and specific tune up for the specific model in the batch with a specific config

more

Trace use is not consistent. When running lts the trace is null.
Ex: in LookaheadSutTrace#runConcreteLookaheadTrace, sutTrace.sendInput is given a null trace.

If we are to store a fresh output value stack in the Trace instance, then we should have
access to this instance whenever we receive an output from the system.

I think what would work best are factory methods in the current Trace class.

So we would no longer have to give it as a parameter. It's a somewhat error prone approach,
but if Trace is used to store the state for each run, it is a reasonable approach.

abslearning.trace.TraceState is not used. Maybe we should delete it?

There is no clear decoupling in code between the various components. Currently, layers are
implemented via inheritance, which does not provide for a flexible solution. A pipes and
filters implementation would be much better and more in line with the theoretical description.

We currently use python in many stages of the process. All stages should be defined and
efforts should be directed towards converging to a Java only implementation.