Moses-support Digest, Vol 121, Issue 29

Send Moses-support mailing list submissions to
moses-support@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu

You can reach the person managing the list at
moses-support-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."


Today's Topics:

1. Re: How to refresh phrase tables after updating FF weights?
(Ulrich Germann)
2. Re: How to refresh phrase tables after updating FF weights?
(Lane Schwartz)
3. Re: How to refresh phrase tables after updating FF weights?
(Lane Schwartz)


----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Nov 2016 17:07:31 +0000
From: Ulrich Germann <ugermann@inf.ed.ac.uk>
Subject: Re: [Moses-support] How to refresh phrase tables after
updating FF weights?
To: Lane Schwartz <dowobeha@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CAHQSRUo1ihtsDs-RzivQ6Ms3XBLgYTwE=gBdAkh-6rvoagb6FA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 <dowobeha@gmail.com> 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
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>


--
Ulrich Germann
Research Associate
School of Informatics
University of Edinburgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20161114/c64ef008/attachment-0001.html

------------------------------

Message: 2
Date: Mon, 14 Nov 2016 11:19:59 -0600
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] How to refresh phrase tables after
updating FF weights?
To: Ulrich Germann <ugermann@inf.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CABv3vZk_3+jW_Wogn4qF1nnKoc6oph+GU9TpXdA+uFYWkEteJg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 <ugermann@inf.ed.ac.uk>
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 <dowobeha@gmail.com> 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
>> Moses-support@mit.edu
>> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20161114/1a8a00d1/attachment-0001.html

------------------------------

Message: 3
Date: Mon, 14 Nov 2016 13:05:13 -0600
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] How to refresh phrase tables after
updating FF weights?
To: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CABv3vZmu9yF9iF8iSHjZqStd=rbq+nyrCodrkiit5wr8BqABpw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 <dowobeha@gmail.com> 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 <ugermann@inf.ed.ac.uk>
> wrote:
>
>>
>>
>> On Mon, Nov 14, 2016 at 5:01 PM, Lane Schwartz <dowobeha@gmail.com>
>> 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 <hieuhoang@gmail.com>
>>> 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 <
>>>> michael.j.denkowski@gmail.com> 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 <dowobeha@gmail.com>
>>>>> 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 <
>>>>>> michael.j.denkowski@gmail.com> 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 <dowobeha@gmail.com>
>>>>>>> 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 <dowobeha@gmail.com>
>>>>>>>> Date: Sun, Nov 13, 2016 at 7:34 PM
>>>>>>>> Subject: How to refresh phrase tables after updating FF weights?
>>>>>>>> To: "moses-support@mit.edu" <moses-support@mit.edu>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20161114/f8116c4e/attachment.html

------------------------------

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


End of Moses-support Digest, Vol 121, Issue 29
**********************************************

Tweet