As explained before the subject of the thesis is to create a generic framework that can handle the generation of rule-feedback. An essential property of any generic framework is that it can be instantiated on a particular domain. In this case the instantiation will need a

**parser**and a

**solver**for a specific domain. This is not a real surprise since these objects are always needed when a tool is constructed. Furthermore, an

**equality module**can be given to the framework. Such a module can be used to check two terms on semantic equality instead of syntactic equality. This is needed because in some cases a teacher would want to allow an answer to be either

*3/2*or

*6/4*as long as the students calculates it correctly. In other situations the answers may only consists of simplified terms, hence the equality may only succeed on the term

*3/2*.

After instantiation the framework is able to generate rule-feedback for a particular domain. This generation is done in four phases, each of them requiring more information and resources. Phases that need more input are of course able to generate better feedback. Notice that they 'are able to', they do not necessarily generate better feedback. The instantiated framework will give you a change for better feedback, but the default feedback will be on the same level as current tools. Thus it is a change on a gain, never a loss.

Phase zero is able to generate feedback with only the current term and the previous term. These two terms are always available since a student will have to take a step before rule-feedback can be generated. The algorithm of this phase will calculate the answer, e.g. the term a student has to supply as final result, of both terms and compare those. When these answers are equal a correct step has been taken, otherwise the student has done something wrong. The feedback generated in this phase is only 'correct' or 'incorrect' because we have no further information about the intentions of the student.

Within phase one the student will supply the rule he wanted to apply. The algorithm of this phase will check whether the rule was correctly applied and whether the rule was correct. The later is easily done by using the algorithm of phase zero. When this delivers an 'incorrect' the rule was wrong. Checking for a correct application is a matter of applying the rule to the previous term and checking the result against the current term. When these are syntactically equal the rule was applied correctly.

The feedback in this phase can let the student know in which area he made a mistake. Either a mistake in the rule itself or in the application. This will at least be more of a help to a student then a simple 'incorrect'.

The second phase needs more input from the programmer. A set of rewrite-rules defining the allowed actions of the domain will need to be defined as input. From this set the algorithms of this phase will 'guess' the rule a student wanted to apply. When an error has been made the feedback can contain hints about this rule and pointers to explanations or examples.

In the third and last phase the programmer can also supply a set of 'buggy'-rules. These rewrite-rules contain patterns of common misconceptions. By finding a path between the current and previous term with the allowed and buggy-rules the algorithm of this phase can identify a mistake with a high precision. The algorithm for this is well defined by Hennecke, a short English overview can be found here. Feedback from this phase can involve a specific explanation about the mistake, maybe accompanied by an example of a correct rule.

The explanation of the second phase mentions that the algorithm 'guesses' the rule. This 'guessing' is not completely worked out yet, it is actually a large part of the thesis. Algorithms for the other phases are already defined and only need to be implemented in a generic fashion. The result will be a practical implementation combined with formal research.

Everything a master thesis needs, right?