Problem parser should be implemented and some more test problems added.

We could benefit from creating more rules; it should save fitness function from losing gradient.

Possible implementation: run DOMLEM many times, each time with different order of examples and criterion.

Prepare framework for automated testing

http://buildr.apache.org/

Maybe by asking DM one more time about his preferences or just shutting everything down

It is rather a simulation issue

It should be configurable if we want to use average or max in quantiles.

Actually we do not know when scenarios are regenerated. This should be configurable

We need basic ant build for project.

Basic:

• compile
• run unittests

Value of consistency used by DOMLEM algorithm should configurable

see title

http://code.google.com/p/specs/wiki/UsingMockito

1. Refactoring
2. Brief option

1. Move out ProblemElement
2. Prepare new Problem class compatible with parser

It should be possible to put utility function for supposed decident in problem specification.

When presenting solution for marking them as good/not good DM should be able to filter solutions not in pareto frontier.

It shouldn't be necessary to specify bounds in binary variables

Change all invocations of new HashMap... to factory f. Map()

We need to handle this whole hierarchy proper way. Possibly eliminating ScoreKeeper. Unittests needed also

Find out why on simple one criteria problem best solution sometimes is getting worse

Probably add as ant task

Refactoring may be done when dealing with solution classes

First generate scenarios, then check if initial solution is feasible