4.8 Trace formats
[ Guide contents | Chapter contents | Next section: 4.9 Algorithms | Previous section: 4.7 File Formats ]
This section explains how to read the output of the generator and recognizer
traces. Traces are produced by the set tracing command described in
section 4.5.6.1.
The amount of detail shown in the trace display is set by the tracing level.
The level argument to the set tracing command can range from 0 to
3, where 0 is no tracing at all and 3 is the most detailed level of tracing.
The purpose of the generator trace is to allow the user to see how a lexical
form is processed through multiple recursive calls to the generator. The
generator algorithm used to process the form is described in
section 4.9.1.
There are three levels of tracing differing in the amount of detail they
display: Level 1 gives the least amount of detail, level 2 (the default) gives
a moderate amount of detail, and level 3 gives the most detail.
Figure 4.16
is a level 1 generator trace of the lexical form `fox+s (taken from the
English example). The only difference from no tracing at all is that the RESULT
line is displayed. This line differs from the normal result that is returned
because it prints all NULL symbols in the output surface form.
Figure 4.16 Level 1 generator trace
Figure 4.17
is from a level 2 generator trace for the form `fox+s. To limit the size
of the trace, the Gemination rules (14 and 15) were turned off. Line numbers
and column numbers are printed here for reference in the description that
follows. Each description refers to an element beginning at the line and column
indicated.
Figure 4.17 Level 2 generator trace
- Line 1: Input line. Lexical form input to the generator function.
- Line 19: RESULT line. Surface form produced by the generator function. At
the point where the input lexical form is empty and each automaton is in a
final state, the trace shows that the generator has recorded a result. The
generator continues looking for additional results (lines 21 and following).
- Column 1: Level number (all lines except 1, 19, and 42). This represents
the level of recursion. Level 0 represents the initial invocation of the
generator. Notice that the number coincides with the number of characters in
the result string so far.
- Column 1: Backtracking indicator (lines 10, 11, 13). The symbol -
indicates that the generator is blocked at that level. The symbol <
indicates that the generator is backtracking (that is, returning to a lower
level to try another path).
- Column 2: Input pair (lines 2-9, 12, 14-16). This is the lexical:surface
pair (from the set of feasible pairs) that is currently being considered by the
generator (for example, f:f on line 4). The rest of the line shows the
results of stepping the automata with the pair as input. The results are
indicated by either a new state configuration (for example, line 5) or a
BLOCKED BY RULE message (for example, line 10).
- Lines 10, 13: BLOCKED BY RULE message. Indicates that a feasible pair
input to the function that steps the automata caused a rule to fail. Gives the
number and name of the rule (from the header line of the state table) that
failed.
- Columns 3-17: State configuration (lines 2-9, 11-12, 14-17). These are
the
current states of each of the rules. The leftmost number is the state of rule
1, the second is rule 2, and so on.
- Column 18: Result (lines 4-9, 11-12, 14-17). This is the current value of
the result string.
- Lines 21-41: The generator continues to backtrack, looking for other
possible paths to a result, until finding no other path it returns to its
initial state.
There is one other tracing message not exemplified in the above
display. This is the END OF INPUT message. It indicates that the end of the
input form has been reached but the generator function has failed on the rule
specified because it was not in a final state. For example,
END OF INPUT, FAILED RULE 4: Palatalization
would indicate that when the end of the input form was reached, rule 4 was not
left in a final state.
Figure 4.18 Level 3 generator trace
Figure 4.18
is part of a level 3 trace for the same form. The level 3 trace differs from
the level 2 trace in how it displays rule failures that block the generator.
Compare line 10 in the level 2 trace with lines 10 and 11 of the level 3 trace.
The level 3 trace explicitly shows what state the automata are in after
stepping them. In line 10 of the level 3 trace we can see that the proposed
input pair puts rule 3 in state 0, which means that it fails. Notice that the
rest of the state array is filled with question marks. This is because if one
rule fails the whole configuration fails, so the rest of the rules are not even
tried. (This shows that even though conceptually the automata operate in
parallel they must still be stepped one at a time).
The purpose of the recognizer trace is to allow the user to see how a surface
form is processed through multiple recursive calls to the recognizer. The
recognizer algorithm used to process the form is described in
section 4.9.1.
There are three levels of tracing differing in the amount of detail they
display: level 1 gives the least amount of detail, level 2 (the default) gives
a moderate amount of detail, and level 3 gives the most detail.
Figure 4.19 Level 1 recognizer trace
Figure 4.19
is a level 1 recognizer trace of the surface form foxes (taken from the
English example). Like the level 1 generator trace, the level 1 recognizer
trace displays the RESULT line but does not show the feasible pairs as they are
tried or the states of the rules. However, it does display a record of how the
recognizer moves through the lexicon, either with an ENTERING} or a BACKING UP
message.
Figure 4.20
is from a level 2 recognizer trace of the form foxes. To limit the size
of the trace, the Gemination rules (14 and 15) were turned off. Line numbers
and column numbers are printed here for reference in the description that
follows. Each description refers to an element beginning at the line and column
indicated.
Figure 4.20 Level 2 recognizer trace
- Line 1: Input line. Surface form input to the recognizer function.
- Line 30: RESULT line. At the point where there are no lexicons in the
continuation class of an entry, the input surface form is empty, and each
automaton is in a final state, the trace shows that the recognizer has recorded
a result. The recognizer continues looking for additional results (lines 32 and
following).
- Column 1: Level number (lines 2, 6-11, 13-19, 21-23, 27-28). This
represents the level of recursion. Level 0 represents the initial invocation of
the recognizer. Notice that the number coincides with the number of characters
in the result string so far.
- Column 1: Backtracking indicator (lines 8, 15, 18, 22-23). The
symbol - indicates that the recognizer is blocked at that level. The
symbol < indicates that the recognizer is backtracking (that is,
returning to a lower level to try another path).
- Column 2: Input pair (lines 2, 6-7, 9-11, and so on). This is the
lexical:surface pair (from the set of feasible pairs) that is currently being
considered by the recognizer (for example, f:f on line 9). The results
of stepping the automata with the pair as input are indicated by either a new
state configuration (for example, line 10) or a BLOCKED BY RULE message (for
example, line 15).
- Lines 3, 5, 12, 20, 25: ENTERING LEXICON message. This is the name of the
sublexicon that the recognizer is about to search.
- Lines 4, 24, 26: ACCEPTING NULL ENTRY message. message} Indicates that a
null lexical entry (that is, an entry whose lexical item is the NULL symbol)
has been accepted.
- Line 22: BLOCKED IN LEXICON message. Indicates that no lexical entry
could
be found in the current lexicon that continues with the input pair under
consideration. The remaining part of the input form is displayed on the line
(in line 22 it happens that nothing is left of the input form).
- Lines 108, 110: BACKING UP message. Indicates that there were no further
sublexicons left in the continuation class, so the recognizer must back up to
the previous lexicon branch.
- Lines 8, 15, 18: BLOCKED BY RULE message. Indicates that a feasible pair
input to the function that steps the automata caused a rule to fail. Gives the
number and name of the rule (from the header line of the state table) that
failed.
- Columns 3-17: State configuration (lines 2, 6-7, 9-11, and so on). These
are the current states of each of the rules. The leftmost number is the state
of rule 1, the second is rule 2, and so on.
- Column 18: Result (lines 6-7 and so on). This is the current value of the
result string.
- Lines 108-111: The recognizer continues to backtrack, looking for other
possible paths to a result, until finding no other path it returns to its
initial state.
The END OF INPUT message may also occur in a recognizer trace. See
section
4.8.1
on the generator trace for an explanation of it.
Figure 4.21 Level 3 recognizer trace
Figure 4.21
is part of a level 3 trace for the same form. Like level 3 of the generator
trace, level 3 of the recognizer trace explicitly shows the state array when a
rule fails. Compare line 8 of the level 2 trace with lines 18 and 19 of the
level 3 trace. In addition, the level 3 recognizer trace shows pairs that are
weeded out by the lexicon even before they are tried with the rules. Compare
lines 3-4 of the level 2 trace with lines 3-10 of the level 3 trace. In lines
4-9 the level 3 trace shows explicitly several pairs that are tried but
immediately fail. Since the recognizer is at the beginning of the input form,
the only possible feasible pairs to try are those whose surface character is
0 (the NULL symbol) or f (the first character of the input form
foxes). Rather than trying each of these pairs with the rules, the
recognizer first looks to see if the lexical character of each pair matches any
lexical character available in the sublexicon it is currently searching. In
each case the match fails, indicated by the message LEXICAL CHARACTER NOT
MATCHED. After trying all the pairs, the lexicon accepts the null entry and
enters a new sublexicon. This exhaustive process takes place at each point in
the recognition process where the recognizer is trying a new pair.
[ Guide contents | Chapter contents | Next section: 4.9 Algorithms | Previous section: 4.7 File Formats ]