Hi Per, the note about stack size having little impact on performance should be true for syntax-based as well, and 200 is probably more than enough for most syntax-based systems. Increasing the stack size comes at the cost of additional memory consumption, and more so for syntax-based because the number of stacks is greater than for phrase-based: O(n^2) instead of O(n) where n is source sentence length (though -max-chart-span will often reduce the number in practice).
Phil On 18 Jun 2013, at 20:39, 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
