Hi all, As I said, updating the branch to a recent version of Moses will be a major point on my agenda in June. Once this is done, merging should be easy.
Concerning translation options, if I remember correctly, I am doing an as deep as necessary copy of the StaticData object for every sentence that has a <specOpt> tag. The translation option cache is not copied, just recreated as an empty cache. However, if the <specOpt> is provided with a "name" attribute the StaticData object is saved for that name, and the translation option cache persists and will be reused every time the same name attribute appears. Best, Marcin On 06.04.2012 11:15, Tom Hoar wrote: > Barry, I agree and I especially like the XML markup approach. > > In a larger sense, the use of XML markup is growing. If/when this > feature is merged into the trunk, I suggest a larger review of all > markup codes to ensure conflicts don't arise between stand-alone vs > xmlrpc/server use of markups, and the various tags themselves. > > For example, the documentation for -xml-input forced translation says, > "The words have to be surrounded by tags, such as<np...> and</np>. The > name of the tags can be chosen freely." The manual itself, and this > support give examples including<np>,<n>,<xml> etc. > > Is it time to set a specific tag for forced translation so conflicts > don't arise with the reserved features tags like<zone>,<wall>, > <specOpt> and the use of xml-rpc tags in mosesserver? Or, should there > be a way to declare tag names in the moses.ini file to users can > customize them without conflicts? > > Tom > > > On Fri, 6 Apr 2012 09:26:42 +0100, Barry Haddow > <[email protected]> wrote: >> Hi Marcin >> >> This sounds like a pretty useful feature. How hard would it be to get >> it >> merged into trunk? How does it interact with Moses caching/pruning of >> translation options? >> >> cheers - Barry >> >> On Friday 06 Apr 2012 07:16:01 Marcin Junczys-Dowmunt wrote: >>> At the moment the branch is based on a Moses version from >>> September/October 2011. I am scheduled to do an update to the >>> current >>> version in the second half of June. >>> >>> Best, >>> Marcin >>> >>> On 06.04.2012 01:25, Prashant Mathur wrote: >>>> Hi Marcin, >>>> This is very close to what we need. >>>> >>>> Thanks, >>>> Prashant >>>> >>>> -----Original Message----- From: Marcin Junczys-Dowmunt >>>> Sent: Thursday, April 05, 2012 8:05 PM >>>> To: Prashant Mathur >>>> Subject: Re: [Moses-support] Adding special instructions to the >>> decoder >>>> via input >>>> >>>> Hi, >>>> take a look at the WIPO branch of Moses. We have something very >>> similar, >>>> but thread-safe. You can specify weights and other moses >>> parameters by >>>> using<specOpt switches="-lm 0.5 -tm 2 -v 2"> anywhere in a >>> sentence. >>>> The weights specified in one sentence do not affect translation of >>>> another sentence. >>>> >>>> Best, >>>> Marcin >>>> >>>> On 05.04.2012 17:54, Prashant Mathur wrote: >>>>> Hi all, >>>>> >>>>> We are trying to update feature weights dynamically during >>> decoding. We >>>>> are doing this by adding additional lines of input, delimited >>> with a >>>>> special token to tell Moses to update weights. >>>>> >>>>> For example, >>>>> ---- >>>>> First sentence. >>>>> @CMD@ weight-l=0.5 >>>>> Change the LM weight for this sentence. >>>>> ---- >>>>> While debugging our new code, we noticed that several lines of >>> the input >>>>> were read before being translated. >>>>> >>>>> For instance, this is the input file: >>>>> sentence0 >>>>> @CMD@ weight-l=0.5 >>>>> sentence1 >>>>> @CMD@ weight-l=0.3 >>>>> sentence2 >>>>> >>>>> Whenever a @CMD@ line is read, we execute the corresponding >>> command to >>>>> change the weights. So we would expect all three sentences to be >>>>> translated with different weights. >>>>> Instead what happens is that all the commands are executed before >>>>> translating *any* sentence, so that all sentences are translated >>> with >>>>> the last modified weights (i.e weight-l=0.3) >>>>> >>>>> This happens when the inputfile is given as an argument (to -i) >>> and also >>>>> when it is read from the stdin. >>>>> Only if we type the lines to the console one by one do we get the >>>>> expected result. >>>>> >>>>> Is there any way to force Moses to read and process each line at >>> a time? >>> >> _______________________________________________ >> Moses-support mailing list >> [email protected] >> http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support > -- dr inż. Marcin Junczys-Dowmunt Uniwersytet im. Adama Mickiewicza Wydział Matematyki i Informatyki ul. Umultowska 87 61-614 Poznań _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
