Hi Wilker > One question would be: > When I am implementing a stateful feature I have to implement *const > FFState* EmptyHypothesisState() const*. > What is this method expected to return? I don't quite get "return the > state associated with the empty hypothesis for a given sentence", if > someone could please give me a little more insight on that I'd be grateful.
The 'empty hypothesis' contains no target words, and covers no source words, so the empty feature state is whatever state is appropriate for this feature function and hypothesis. The empty feature state is passed to Evaluate() when adding an initial phrase pair. For example, the language model features would use the begin-sentence symbol as their state associated with the empty hypothesis. Reordering features may use some state which fakes a previous phrase position before the start of the sentence. It depends on your feature. > > The comment (not a complaint!) would be: > The code that handles feature functions (or score producers) is rather not > object-oriented, I say that because although there is a hierarchy of > classes (at some extent), along the code this hierarchy is not exploited. > For instance, at some point I had to dig into the code and force my score > producers to be given a chance to do some pre-processing just before a > sentence is decoded. > I cannot rewrite it all right now, but I planning (and would like) to. For > the time being I made it in away that new score producers can use an API > that eases integration, but left the traditional score producers unchanged. > Also, things seem a bit too decoupled, at some point a TranslationSystem > might know of a ScoreProducer that is actually not ready to run or the > Manager knows the producer while the System doesn't. We could use some > factories and control how score producers get created. > Finally, there are null pointers around at running time. It seems Moses > was first written using a JavaBeans-like pattern, where we build objects > and later set them to valid states, whereas nowadays we should (as the code > grows) probably use safer patterns making sure objects are always in valid > states (from the moment they are built) , being most of them immutable > whenever possible. All fair comments. There's room for more hooks in ScoreProducer, for instance to force the FF to be pre-calculated in the TranslationOption. The FF interface was added after moses was at least 2 years old, so it was retro- fitted onto the core features such as phrase table and language model. > > The second question (actually 2 in 1) would be: > Is there anything like a "Moses re-factoring team" and may I sign up to > it? > There's really only this mailing list. There's a moses-developer mailing list but it's not used much. There's clearly space for refactoring though... 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
