<?xml version="1.0" standalone="yes"?>
<Paper uid="C94-2161">
  <Title>Anytime Algorithms fl)r Speech Parsing?*</Title>
  <Section position="4" start_page="0" end_page="997" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> The idea of '%nylime algorithms&amp;quot;, which has been around in the tieht of plmming for some time 1, has recently been suggested for application in natural language and speech l)rocessing (NL/SP) 2. An anytime algorithm is an algorit.hm &amp;quot;whose quality of results (legrades graceflflly a~s computation time decreases&amp;quot; (\[Russell attd Zilt)erstein 1991\], p. 212). In the following we will first give a more specilic definition of which properties allow an algorithm to be implemented and used as an anytime algorithm. We then apply this knowledge to a specitic aspect of NL/SP, namely parsing algorithms in a speech understanding system. In the Appendix we present the A I)C protocol which supports anytime computations.</Paragraph>
    <Paragraph position="1"> We will discuss these matters in the framework of the Verbmobil joint research project a, where we are working on the implementation of an incremental chart parser 4. The conception of this I)arser has been derived from earlier work by the llrst author 5.</Paragraph>
    <Paragraph position="2"> lef. e.g. \[llussell mM Zilberstein 1991\] P'so \[Wahlster 1992\] in his invited talk at CO1,\[N(I-92 a ~lThe Verbmnbil joint research project has been defined in the  they lend themselves to preemptive scheduling techniques (i.e., they cart bc suspended and resumed with negligible overhead), they can be terminated at any time and will return SOl\[le answer~ and the attswers reI, urned iml)rove in some weltbehaved maturer as a function of time.</Paragraph>
    <Paragraph position="3"> Unforl,unately this characterization does not make a clear distinction between the intplementation of an algorithm and tile algorithm as such.</Paragraph>
    <Paragraph position="4"> Point (1) is true of a great many Mgorithms implemented on preenq)tive operatirLg systems.</Paragraph>
    <Paragraph position="5"> Poin~ (2) can be made true for any algorithm by adding all explicit Result slot, that is I)reset by a wdue. denoting a w)id result. I,et us call the implementation of an anyl;inm algorithm an anytime producer. Accordingly we ttanle the entity interested in the result of such an anytime computation the anytime consumer. Figurc 1 shows two such processes in a tightly coupled synchronization loop. Figure 2 shows the same communicating processes decoupled by the introduction of the Result slot. Note that synrhronisation is much cheaper in terms of perceived complexity R)r the programrne.r and runtime synehronisation overhead (just the time to cheek and eventually traverse the mutual exclusion barrier). In such an architecture producer and consumer work under a regime that allows the consmner to interrupt the producer at any lime and dentand a result. The risk that the consumer incurs by such flexibility is a eertMn non-zero probability that  protected by a simple mutual exclusion barrier.</Paragraph>
    <Paragraph position="6"> Point (3) is surely a much too strong restriction, since it is not always possible to define what exactly an improvement is for any given algorithm. In NL/SP, where we are often dealing with scored hypotheses, it is difficult, if not impossible, to devise algorithms that supply answers that improve monotonically as a flmction of invested computational resources (time or processing units in a parallel architecture).</Paragraph>
    <Paragraph position="7"> We propose the following characterization of anytime algorithms: An algorithm is fit to be used as an anytime producer if its implementation yields a program that has a Result Production Granularity (RPG) that is cmnpatible with the time constraints of the consumer.</Paragraph>
    <Paragraph position="8"> The notion of RPG is based on the following observation: Computations being performed on fnite state machines do not proceed directly from goal state to goal state. Instead they go through arbitrarily large sequences of states that yield no extractable or intelligible data to an outside observer. To interrupt a producer on any of these intermediate states is fruitless, since the result obtained could at best, according to the observation made on point (2) above, be the result that was available in the last goal state of the producer. From the point of view of the consumer the transitions from goal state to goal state in the producer are atomic transactions.</Paragraph>
    <Paragraph position="9"> The average length of these transactions in the algorithm correspond to average time intervals in the implementation, so that we can speak of a granularity with which results are produced.</Paragraph>
    <Paragraph position="10"> The time constraints under which the eonsumer is operating then give the final verdict if the implemeutation of an algorithm is usable as an anytime producer. Let us illustrate this by an example: In a real-time NL/SP-system tim upper bound for the RPG will I, ypieally be in the range of 10 lOOms. That is, a producer implemented with such an RPG ofl&gt;rs the consumer the chance to trade a 500ms delay for 5 to 50 fllrther potential solutions.</Paragraph>
    <Paragraph position="11"> Note that goal states can also be associated with intermediate results in the producer algorithm. Conceptually there really is not much of a difference between a result and an intermediate result,, but in highly optimized implementations there might be the need to explicitly export such intermediate results, due to data representation incompatibilities or simply because the data might be overwritten by other (non-result) data.</Paragraph>
    <Paragraph position="12"> Section 4 gives an example of how the RPG of an implementation can be reduced by identifying intermediate goal states that yield information which is of interest to the consumer.</Paragraph>
  </Section>
class="xml-element"></Paper>