<?xml version="1.0" standalone="yes"?>
<Paper uid="P98-1109">
  <Title>Know When to Hold 'Em: Shuffling Deterministically in a Parser for Nonconcatenative Grammars*</Title>
  <Section position="7" start_page="666" end_page="667" type="evalu">
    <SectionTitle>
6 Performance Comparison
</SectionTitle>
    <Paragraph position="0"> In order to evaluate the reduction in the search space that is achieved by shuffling deterministically, the parser with the optimized shuffle constraints and the parser with the nonoptimized constraints were each tested with the same grammar of German on a set of 30 sentences of varying length, complexity and clause types. Apart from the redefinition of the shuffle relation, discussed in the previous section, the only differences between the grammars used for the optimized and unoptimized tests are the addition of CODE values for each domain element in the optimized version and the constraints necessary to propagate these code values through the intermediate structures used by the parser.</Paragraph>
    <Paragraph position="1"> A representative sample of the tested sentences is given in Table 2 (because of space limitations, English glosses are not given, but the words have all been glossed in SS2), and the performance results for these 12 sentences are listed in Table 1. For each version of the parser, time, choice points, and calls are reported, as follows: The time measurement (Time) 5 is the amount of CPU seconds (on a Sun SPARCstation 5) required to search for all possible parses, choice points (ChoicePts) records the number of instances where more than one disjunct may apply at the time when a constraint is resolved, and calls (Calls) lists the number of times a constraint is unfolded. The number of calls listed includes all constraints evaluated by the parser, not only shuffle constraints. Given the nature of the ConTroll implementation, the number of calls represents the most basic number of steps performed by the parser at a logical level. Therefore, the most revealing comparison with regard to performance improvement between the optimized and nonoptimized versions is the call factor, given in the last column of Table 1.</Paragraph>
    <Paragraph position="2"> The call factor for each sentence is the number of nonoptimized calls divided by the number of optimized calls. For example, in T1, Er hilfl ihr, the version using the nonoptimized shuffle was required to make 4.1 times as many calls as the version employing the optimized shuffle.</Paragraph>
    <Paragraph position="3"> The deterministic shuffle had its most dramatic impact on longer sentences and on sentences con- null interpreter running in Prolog. However, the relative time differences between sentences confirm that the number of calls roughly reflects the total work required by the parser.  taining adjuncts. For instance, in T7, a verb-first sentence containing the adjunct schnell, the optimized version outperformed the nonoptimized by a call factor of 28.3. From these results, the utility of a deterministic shuffle constraint is clear. In particular, it should be noted that avoiding useless results for shuffle constraints prunes away many large branches from the overall search space of the parser, because shuffle constraints are imposed on each node of the hierarchical structure. Since we use a largely bottom-up strategy, this means that if there are n solutions to a shuffle constraint on some daughter node, then all of the constraints on its mother node have to be solved n times. If we avoid producing n - 1 useless solutions to shuffle, then we also avoid n - 1 attempts to construct all of the ancestors to this node in the hierarchical structure.</Paragraph>
  </Section>
class="xml-element"></Paper>