Thanks, I got it! As for collaborating, I'm trying to gather more information about it.
Cheers, Wilker. On 16 November 2011 12:52, Barry Haddow <bhad...@staffmail.ed.ac.uk> wrote: > 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. > > -- Wilker Aziz http://pers-www.wlv.ac.uk/~in1676/
_______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
