On Friday 22 July 2011 03:50, Hieu Hoang wrote: > true, & there's no right answer to it. > > I suppose 1 goal of the trunk is to make sure that the core functionality > of translating isn't affected too much, in terms of quality, speed, or > memory. ANother goal is to make not to overburden the API with things > no-one else uses or implement. > > therefore, i think a good strategy is to branch & do what you like >
Hi Hieu I'm not sure I see the point of implementing this in a branch and never merging. That's not a branch, it's a fork. The point of doing a small change like this in a branch would be so that the LM interface experts (ie you and Ken and ...) could have a look at it before it gets merged in. As regards how to implement the interface changes, what would be the consequences of having other LM implementations throw an exception or an assert for ngram_length? I think returning -1 is a very bad idea, especially as the return value is probably a size_t, and returning 0 could also lead to subtle and confusing behaviour. However if there is a return value with the semantics of "don't know" then that would be the ideal solution. cheers - Barry -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
