Difference between revisions of "Talk:Automatically trimming a monodix"

From Apertium
Jump to navigation Jump to search
Line 40: Line 40:
   
 
==Worse is better==
 
==Worse is better==
If it's difficult to get a complete lt-trim solution that handles &lt;g&gt; and &lt;j&gt; perfectly a stop-gap might be to distribute a dictionary of the multiwords with the language pair, and leave only "simple" words in the monolingual package dictionary. The multiwords would be manually trimmed to the pair, the simple words trimmed with lt-trim, and a new <code>lt-merge</code> command would merge the two compiled dictionaries (as seperate sections).
+
If it's difficult to get a complete lt-trim solution that handles &lt;g&gt; perfectly a stop-gap might be to distribute a dictionary of the multiwords with the language pair, and leave only "simple" words in the monolingual package dictionary. The multiwords would be manually trimmed to the pair, the simple words trimmed with lt-trim, and a new <code>lt-merge</code> command would merge the two compiled dictionaries (as seperate sections).
   
 
(An lt-merge command might also be helpful when compiling att transducers, which makes anything that looks like punctuation [[inconditional]], and anything else standard.)
 
(An lt-merge command might also be helpful when compiling att transducers, which makes anything that looks like punctuation [[inconditional]], and anything else standard.)

Revision as of 07:12, 7 February 2014

Implementing automatic trimming in lttoolbox

The simplest method seems to be to first create the analyser in the normal way, then loop through all its states (see transducer.cc:Transducer::closure for a loop example), trying to do the same steps in parallel with the compiled bidix:

trim(current_a, current_b):

  for symbol, next_a in analyser.transitions[current_a]:

    found = false

    for s, next_b in bidix.transitions[current_b]:
      if s==symbol:
         trim(next_a, next_b)
         found = true
    if seen tags: 
      found = true

    if !found && !current_b.isFinal():
      delete symbol from analyser.transitions[current_a]

    // else: all transitions from this point on will just be carried over unchanged by bidix

trim(analyser.initial, bidix.initial)
product automaton for intersection

Trimming while reading the XML file might have lower memory usage, but seems like more work, since pardefs are read before we get to an "initial" state.


https://github.com/unhammer/lttoolbox/branches has some experiments


A slightly different approach is to create the product automaton for intersection, marking as final only state-pairs where both parts of the state-pair are final in the original automata. Minimisation should remove unreachable state-pairs.


Unbalanced loops

Say analyser is the regex j+<n> while bidix is j+jjj<n> – ideally we could "trim" analyser to j+jjj<n>, but is it possible to do that in a tractable manner?

Worse is better

If it's difficult to get a complete lt-trim solution that handles <g> perfectly a stop-gap might be to distribute a dictionary of the multiwords with the language pair, and leave only "simple" words in the monolingual package dictionary. The multiwords would be manually trimmed to the pair, the simple words trimmed with lt-trim, and a new lt-merge command would merge the two compiled dictionaries (as seperate sections).

(An lt-merge command might also be helpful when compiling att transducers, which makes anything that looks like punctuation inconditional, and anything else standard.)

#-type multiwords

An idea for implementation: first "preprocess" the bidix so it has the same format as the analyser, ie. instead of "take# out<vblex>" it has "take<vblex># out".

Say you have these entries in the bidix:

take# out<vblex>
take# out<n>
take# in<vblex>
take<n>
take<vblex>

You do a depth-first traversal, and then after reading all of "take" you see t=transition(A, B, ε, #). You remove that transition, and instead add the result of unpretransfer(t), which returns an ε-transition into a new transducer that represents these partial analyses:

<vblex># out
<n># out
<vblex># in

Compounds vs trimming in sme

The sme.lexc can't be trimmed using the simple HFST trick, due to compounds.

Say you have cake n sg, cake n pl, beer n pl and beer n sg in monodix, while bidix has beer n and wine n. The HFST method without compounding is to intersect (cake|beer) n (sg|pl) with (beer|wine) n .* to get beer n (sg|pl).

But HFST represents compounding as a transition from the end of the singular noun to the beginning of the (noun) transducer, so a compounding HFST actually looks like

((cake|beer) n sg)*(cake|beer) n (sg|pl)

The intersection of this with

(beer|wine) n .*

is

(beer n sg)*(cake|beer) n (sg|pl) | beer n pl

when it should have been

(beer n sg)*(beer n (sg|pl)


Lttoolbox doesn't represent compounding by extra circular transitions, but instead by a special restart symbol interpreted while analysing. When we have lt-trim we will be able to make it understand compounds by e.g. restarting on +