12 Debug

In this chapter, we explain how grammars can be debugged. Due to the concurrent constraint-based implementation of the XDK solver, it cannot tell you spot-on what went wrong e.g. if you do not get the desired analysis. Rather, debugging XDG grammars proceeds in an indirect fashion, by individually turning off dimensions and principles.

12.1 Too few solutions

Debugging is easiest with the GUI (xdk.exe). Here, the menu Dimensions allows you to individually turn off the dimensions, and the menu Principles to individually turn off the principles of the grammar. Of course, this can also be done without the GUI by changing the grammar itself (turn off dimensions or principles by not using them).

Here is the basic recipe for debugging, e.g. in the case when a sentence which should yield a solution does not. For instance, assuming that your grammar has two dimensions, first try the two dimensions individually. If you do not get a failure then, but if you do get a failure when using both of the dimensions, then something about the interaction of the two dimensions must be wrong. That means typically either that:

• a word is lexically ambiguous, and one of the entries works only for one dimension, and the other only for the other dimension, or
• you are using a multi-dimensional principle which causes the failure

12.2 Too many (structurally equivalent) solutions

If you get too many solutions, and each of the solutions is structurally equivalent, a common cause is the combination of two things: 1) that your grammar generates too many lexical entries, and 2) you use the principle principle.entries (Entries). This principle enumerates all different lexical entries, even if they make no structural difference.

The solution to this problem is twofold: 1) deactivate "principle.entries", 2) reduce the number of disjunctions. The reason for 2) is that even though your grammar does not show it and the solver can cope quite well with lexical ambiguity, it is always wise to keep the number of lexical entries as low as possible for efficiency. The key to doing that is to encode the disjunction into sets. For example,

     ...
     dim idlp {end: {iobj: {ff | iosf | piosf} } } }
     ...

generates three lexical entries, whereas:

     ...
     dim idlp {end: {iobj: {ff iosf piosf} } } }
     ...

only generates one and has the same effect: the indirect object (iobj) can either go into the ff, the iosf, or the piosf.

This encoding of disjunctions into sets also works for in valencies: you could encode:

     ...
     dim id {obj? | iobj?}
     ...

into

     ...
     dim id {obj? iobj?}
     ...

given that the models on the id dimension are always trees, which means each node can have at most one incoming edge, which in turn means that the incoming edge in the example can only be obj or iobj, but not both.