Thanks, Uli. I am indeed now successfully using ContextScope as you suggest.
I thought I had successfully figured out how to change the weights for a feature, but they seem to be resetting themselves, and I'm currently trying to convince gdb to help me figure out the culprit. In moses/server/TranslationRequest.cpp, I change the weights for a model. I run StaticData::Instance().GetAllWeights().OutputAllFeatureScores(std ::cout, true) before and after doing so, and the print statements confirm that my feature weight has changed. Then, in moses/DecodeStepTranslation.cpp, I do the same print statement StaticData::Instance().GetAllWeights().OutputAllFeatureScores(std::cout, true), and my feature weight is back to the original value. On Mon, Nov 14, 2016 at 11:07 AM, Ulrich Germann <[email protected]> wrote: > Sorry for the late reply. Resetting a cache was what the ContextScope was > originally intended for. The main Idea is that each FF can store anything > on it using it's *this* pointer as a key. So if you want to caching > within a certain context, you set up a new context scope for that piece of > text. When the context scope goes out of scope, everything stored with it > disappears (make sure you use shared pointers and implement proper > destructors for your stuff). DO NOT, and I repeat, DO NOT add your own > FF-specific members to ContextScope. It's already happened to some degree, > but I do not want it to proliferate. The idea is that (a) no code clutter > should build up outside of a FF's implementation. Write your own structure > that stores the stuff YOUR feature function needs and use the this pointer > (or any other pointer that lies wihin the range of this and this + > sizeof(*this), if you need more than one). This is not the most efficient > way of doing this, obviously (there's a std::map involved, and some > locking). If you are concerned about efficiency, consider using > thread-specific pointers that you reset in InitializeForInput (e.g., set a > thread-specific pointer to a shared pointer retrieved from ContextScope to > avoid having to do that every time you call EvaluateWhenApplied(). > > For an example, see InitializeForInput in the Mmsapt implementation here: > https://github.com/moses-smt/mosesdecoder/blob/ > master/moses/TranslationModel/UG/mmsapt.cpp (starts at line 922). > > As for changing feature weights on the fly, tremendous amounts of sofware > engineering seem to have gone into making that as difficult as possible, > firmly bolting weights into place as global variable, just stopping short > of setting them via #define. I think David Madl has done the labor of > coding love to have the weights passed around to the FF, so that they can > be changed, but alas, only in the MMT fork of the Moses decoder at the > modernmt repo, as far as I know. I pleaded long and hard to keep MMT work > in sync with the Moses code base, but was unsuccessful. > > - Uli > > On Mon, Nov 14, 2016 at 1:34 AM, Lane Schwartz <[email protected]> wrote: > >> Hi, >> >> I'm working on some interactive code to enable feature function weights >> to be updated in mosesserver via XML-RPC calls from a client. >> >> One issue that I'm running into (as noted in a comment in XmlOption.cpp), >> is that the phrase tables tend to do some calculations when the decoder >> starts up, using the FF weights that are available at that time. My problem >> is that when those weights are later updated, the scored values are already >> locked into the phrase table entries. >> >> I'm looking for advice on the best way to force the phrase tables to >> re-calculate any such calculations that need to be re-done after feature >> function weights have been updated. Any advice would be appreciated. >> >> Thanks, >> Lane >> >> >> _______________________________________________ >> Moses-support mailing list >> [email protected] >> http://mailman.mit.edu/mailman/listinfo/moses-support >> >> > > > -- > Ulrich Germann > Research Associate > School of Informatics > University of Edinburgh > -- When a place gets crowded enough to require ID's, social collapse is not far away. It is time to go elsewhere. The best thing about space travel is that it made it possible to go elsewhere. -- R.A. Heinlein, "Time Enough For Love"
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
