Hi, Thank you. Now I'm enlightened! Yours, Per Tunedal
On Tue, Jun 18, 2013, at 22:01, Philipp Koehn wrote: > Hi, > > cube pruning combines the best hypotheses with the best rules. > If the cube pruning limit is 2000, then it is very unlikely that as > many different hypotheses are considered. A stack size of 200 > instead of 2000 will only in rare cases make any difference. > > -phi > > On Tue, Jun 18, 2013 at 8:39 PM, Per Tunedal > <[email protected]>wrote: > > > Hi Philip, > > thanks for your thorough answer. Just what I needed! > > > > I've only got one more question: Why such a small stack size as 200 as > > default? Why not 2000 as suggested on the Advanced Features page when > > using decoding with cube pruning for phrase models: > > > > "To get faster performance than the default Moses setting at roughly the > > same performance, use the parameter settings: > > > > -search-algorithm 1 -cube-pruning-pop-limit 2000 -s 2000 > > > > This uses cube pruning (-search-algorithm) that adds 2000 hypotheses to > > each stack (-cube-pruning-pop-limit 2000) and also increases the stack > > size to 2000 (-s 2000). Note that with cube pruning, the size of the > > stack has little impact on performance, so it should be set rather high. > > The speed/quality trade-off is mostly regulated by the cube pruning pop > > limit, i.e. the number of hypotheses added to each stack." > > > > BTW I've tried phrase model decoding as above, but with > > -cube-pruning-pop-limit 1000 to match my chart models. The translation > > quality (BLEU score) improved slightly, compared to the standard > > decoding. And the translation was faster. > > > > Yours, > > Per Tunedal > > > > On Tue, Jun 18, 2013, at 21:17, Philip Williams wrote: > > > Hi Per, > > > > > > the -stack option controls histogram pruning in moses_chart. It's always > > > on and the default stack size is 200 (the same as for phrase-based). > > > > > > If your model is hierarchical or tree-to-string (i.e. no target syntax) > > > then there will be up to two stacks per chart cell: one for X hypotheses > > > and one for S hypotheses. If your model has target syntax then there can > > > potentially be many stacks per cell (one for each distinct LHS label for > > > the hypotheses that cover the span). > > > > > > The pop limit is applied on a per-cell basis and controls the number of > > > hypotheses popped from the cube pruning queue (assuming you're using cube > > > pruning, of course). Once a hypothesis is popped it's added to one of > > > the chart cell's stacks, chosen according to the hypothesis' label. If > > > the stack already contains one or more hypotheses with identical LM state > > > values then the hypotheses are merged into a single stack entry > > > (hypothesis recombination). Finally, the stack is pruned so that it > > > doesn't exceed the maximum number of entries. > > > > > > The default pruning values are probably fine for most models. If you're > > > using both source and target syntax then translation quality is likely to > > > be substantially worse than phrase-based due to syntactic divergence. > > > Solutions for this problem have been proposed in the literature (e.g. > > > David Chiang's "Learning to Translate with Source and Target Syntax" in > > > ACL 2010) but haven't made it into Moses yet. Results for string-to-tree > > > or tree-to-string should be closer to phrase-based. > > > > > > Hope that helps... > > > > > > Phil > > > > > > > > > On 18 Jun 2013, at 17:49, Kenneth Heafield <[email protected]> wrote: > > > > > > > There are a few kinds of pruning in syntactic decoding: > > > > > > > > -ttable-limit sets the max number of target side rules per source rule. > > > > > > > > -cube-pruning-pop-limit controls the beam size aka pop limit even if > > the > > > > algorithm isn't cube pruning. Default 1000. > > > > > > > > I think the parser can also throw out entire source side matches. This > > > > is disabled by default; ask Phil Williams about it. > > > > > > > > Kenneth > > > > > > > > On 06/18/13 12:36, Per Tunedal wrote: > > > >> Hi, > > > >> Is histogram pruning always on? What's the default stack size? Why > > isn't > > > >> it listed among the settings on the Syntax Tutorial page? > > > >> > > > >> How is the search and pruning actually done for hierarchical models? > > > >> When is the histogram pruning done? > > > >> > > > >> I've tested with the settings: > > > >> moses_chart -f trainTreeSyntaxInSourceAndTarget/model/moses.ini < > > > >> fr-sv.test.fr > fr-sv.test.fr.TreeSyntaxInSourceAndTarget.translated > > 2> > > > >> stderrTreeSyntaxInSourceAndTarget.txt > > > >> > > > >> I suppose I got the default cube-pruning-pop-limit 1000, but what > > about > > > >> the histogram pruning? I've read that the stack size isn't much of a > > > >> problem when using cube pruning (Advanced Features page). > > > >> > > > >> BTW The results are very disappointing. > > > >> > > > >> Yours, > > > >> Per Tunedal > > > >> > > > >> PS I've read a lot of books and papers on the subject but got lost in > > > >> the details. A very simplified explanation with the main steps for the > > > >> implementation in Moses would be helpful. > > > >> > > > >> On Tue, Jun 18, 2013, at 17:08, Hieu Hoang wrote: > > > >>> there is historgram pruning in the chart decoder. It's implemented in > > > >>> ChartHypothesisCollection::PruneToSize() > > > >>> there is no threshold pruning > > > >>> > > > >>> > > > >>> On 17 June 2013 21:14, Per Tunedal <[email protected]> > > wrote: > > > >>> > > > >>>> > > > >>>> Hi, > > > >>>> I can't find any settings for e.g. histogram pruning for the > > > >>>> chart-decoder. Is cube pruning the only pruning used by Moses > > > >>>> chart-decoder? > > > >>>> When using cube pruning with a phrase model I suppose both threshold > > > >>>> pruning and histogram pruning are used as well. The cube pruning > > only > > > >>>> affects what new hypothesis to add to the stack, if I've understood > > the > > > >>>> Advanced Features page correctly. > > > >>>> Have I missed something? > > > >>>> Yours, > > > >>>> Per Tunedal > > > >>>> _______________________________________________ > > > >>>> Moses-support mailing list > > > >>>> [email protected] > > > >>>> http://mailman.mit.edu/mailman/listinfo/moses-support > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Hieu Hoang > > > >>> Research Associate > > > >>> University of Edinburgh > > > >>> http://www.hoang.co.uk/hieu > > > >> _______________________________________________ > > > >> Moses-support mailing list > > > >> [email protected] > > > >> http://mailman.mit.edu/mailman/listinfo/moses-support > > > >> > > > > _______________________________________________ > > > > Moses-support mailing list > > > > [email protected] > > > > http://mailman.mit.edu/mailman/listinfo/moses-support > > > > > _______________________________________________ > > Moses-support mailing list > > [email protected] > > http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
