I figured out my problem. It was a C++ rookie mistake on my part. My code was doing this:
ScoreComponentCollection allWeights = StaticData > ::Instance().GetAllWeights(); > ... > allWeights.Assign(ff, ffWeights); In the above, I didn't realize that the assignment was actually calling the copy constructor of ScoreComponentCollection. Thus, allWeights was a local copy of the global ScoreComponentCollection, and the changes I made were only to the local copy. Changing my code to the following fixed the problem: Moses::StaticData::InstanceNonConst().SetWeights(ff, ffWeights); Now, that still doesn't fix the issue that doing this is very non-threadsafe, but for now I can live with that shortcoming. On Mon, Nov 14, 2016 at 11:37 AM, Lane Schwartz <[email protected]> wrote: > I'm changing them globally in TranslationRequest.cpp. Obviously that's not > ideal, but for the experiments I want to run it should be fine. > > But somehow they're getting changed back. > > On Mon, Nov 14, 2016 at 11:25 AM, Ulrich Germann <[email protected]> > wrote: > >> >> >> On Mon, Nov 14, 2016 at 5:01 PM, Lane Schwartz <[email protected]> >> wrote: >> >>> This is getting stranger and stranger. >>> >>> In moses/server/TranslationRequest.cpp, I change the weights for a >>> model. >>> >> >> How do you change the weights? As far as I know they can be changed only >> globally, which is obviously not what you want to do in a server that >> serves many requests. >> >> The easiest way of accomplishing what I believe you are trying to do, in >> my opinion, would be this (and it works only as long as it's one thread per >> sentence, as in the current way multi-threading in Moses is done). >> >> 1. When the TranslationRequest is created, store weights in the context >> scope (see my previous email) >> 2. At the beginning of the Run() member function, retrieve task-specific >> information in a boost::thread_specific_ptr >> 3. Change StaticData::GetAllWeights() to retrieve the weights from a >> thread-specific pointer instead of StaticData. >> >> Do the same thing for all caches. >> >> At one point I think I started implementing that, but I don't think it >> ever made it into the master branch. >> >> - Uli >> >> >>> 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 10:48 AM, Hieu Hoang <[email protected]> >>> wrote: >>> >>>> oh sorry, didn't read your email properly. >>>> >>>> I think all phrase-tables cache. >>>> >>>> On 14/11/2016 16:42, Hieu Hoang wrote: >>>> >>>> and all stateless feature functions? - phrase penalty, word penalty >>>> >>>> Hieu Hoang >>>> http://www.hoang.co.uk/hieu >>>> >>>> On 14 November 2016 at 16:40, Michael Denkowski < >>>> [email protected]> wrote: >>>> >>>>> +Hieu and Uli >>>>> >>>>> Can you guys think of anywhere other than PhraseDictionary >>>>> implementations that Moses would cache a phrase that has been scored with >>>>> a >>>>> language model? Lane is looking for caches that need to be reset if he >>>>> adjusts feature scores on the fly. Any thoughts would be a big help. >>>>> >>>>> Best, >>>>> Michael >>>>> >>>>> On Mon, Nov 14, 2016 at 11:03 AM, Lane Schwartz <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks, Michael. I appreciate the pointer. I'm working with >>>>>> PhraseDictionaryMemory, which doesn't use caching, so something else must >>>>>> be going on. >>>>>> >>>>>> I have an LM that I'm using for testing. I'm using VERBOSE=3 to see >>>>>> what's going on. If I give it weight=100 in the moses.ini file, when the >>>>>> TM >>>>>> loads a particular phrase, the score for that phrase reflects that weight >>>>>> was 100 for my LM. >>>>>> >>>>>> But, if I set weight=1 for that LM in moses.ini, and then updated >>>>>> that weight to be 100 using an XML-RPC call (and a call to StaticData >>>>>> confirms that the weight has been changed), the score that the TM reports >>>>>> for my test phrase indicates that the LM weight it used was the original >>>>>> value (1) and not the updated value (100). >>>>>> >>>>>> Since caching is (presumably) not involved, I'm not sure what is. I'm >>>>>> trying to track down where the phrase collection is scored, so far >>>>>> without >>>>>> much success. >>>>>> >>>>>> >>>>>> On Mon, Nov 14, 2016 at 9:55 AM, Michael Denkowski < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Lane, >>>>>>> >>>>>>> This is probably going to be implementation-specific but the goal is >>>>>>> to force a cache clear on the PhraseDictionary type you're using. In >>>>>>> this >>>>>>> case, we're using Uli's dynamic suffix array phrase table. A null >>>>>>> update >>>>>>> advances the state of the suffix array without actually changing >>>>>>> anything. >>>>>>> Next time it's queried, it sees that the state doesn't match the cache >>>>>>> so >>>>>>> it needs to look everything up again. >>>>>>> >>>>>>> Any check for caching is probably going on in either >>>>>>> GetTargetPhraseCollectionBatch or GetTargetPhraseCollectionLEGACY >>>>>>> for other PhrraseDictionary implementations. >>>>>>> >>>>>>> Best, >>>>>>> Michael >>>>>>> >>>>>>> On Mon, Nov 14, 2016 at 10:34 AM, Lane Schwartz <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is some code in XmlOption.cpp that git blame tells me you >>>>>>>> wrote. :) >>>>>>>> >>>>>>>> + // weight-overwrite: update feature weights, unspecified >>>>>>>>> weights remain unchanged >>>>>>>>> + // IMPORTANT: translation models that cache phrases or >>>>>>>>> apply table-limit during load >>>>>>>>> + // based on initial weights need to be reset. Sending an >>>>>>>>> empty update will do this >>>>>>>>> + // for PhraseDictionaryBitextSampling (Mmsapt) models: >>>>>>>>> + // <update name="TranslationModelName" source=" " >>>>>>>>> target=" " alignment=" " /> >>>>>>>> >>>>>>>> >>>>>>>> I'm writing some similar code to update weights via XML-RPC. I'm >>>>>>>> hitting this problem, but it's not clear to me how to reset the phrase >>>>>>>> tables in this way. Would you be able to point me to anywhere in >>>>>>>> particular >>>>>>>> in the code where this takes place? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lane >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: Lane Schwartz <[email protected]> >>>>>>>> Date: Sun, Nov 13, 2016 at 7:34 PM >>>>>>>> Subject: How to refresh phrase tables after updating FF weights? >>>>>>>> To: "[email protected]" <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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" >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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" >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> 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" >>> >> >> >> >> -- >> 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" > -- 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
