Hi Marcin,

The latest version (d6dbc33) works successfully. Thank you for your help.

Best,
Katsuhito
--
Katsuhito Sudoh
NTT Communication Science Laboratories, Japan
mailto: [email protected]




On Aug 23, 2012, at 17:30, Marcin Junczys-Dowmunt <[email protected]> wrote:

> Hi again,
> OK, you can try now. Pull the latest version and rebuild your reordering 
> model with processLexicalTableMin. I hope it works now.
> 
> By the way: Can someone tell me which options are necessary to make the 
> training script produce a lexical reordering model of the following form:
> 
> f ||| e ||| c ||| scores
> 
> This is currently not supported, but I could also not create one like that.
> Best,
> Marcin
> 
> W dniu 23.08.2012 07:59, Marcin Junczys-Dowmunt pisze:
>> Hi,
>> I will take a look a that. I suppose I did not support or test the type
>> of reordering model you use. It should work with msd-bidirectional-fe .
>> As soon as I have a solution I will let you know.
>> Best,
>> Marcin
>> 
>> W dniu 23.08.2012 07:50, Katsuhito Sudoh pisze:
>>> Hi everyone,
>>> 
>>> I face an problem in multi-thread decoding with a compact binarized 
>>> reordering model
>>> compiled using "processLexicalTableMin", by moses (ver. 2d1cafe).
>>> (described here: 
>>> http://www.statmt.org/moses/?n=Moses.AdvancedFeatures#ntoc6 )
>>> 
>>> Decoding process always fails soon after its start without any decoding 
>>> results.
>>> This only occurs with multi-thread decoding with the compact reordering 
>>> model;
>>> the decoder itself works fine with single-thread decoding
>>> or with an original binarized reordering model produced by 
>>> "processLexicalTable".
>>> 
>>> The reordering model was trained by a standard manner with 
>>> "train-model.perl",
>>> with "mslr-bidirectional-fe" reordering option.
>>> 
>>> 
>>> The following message was printed to stderr when moses failed:
>>>> Offending hypo = this plate and the other end portions of the 
>>>> [100000100011100000000]  [total=-43.779] <<-8.000, -9.000, 0.000, -1.104, 
>>>> 0.000, 0.000, -4.730, 0.000, 0.000, 0.000, 0.000, -29.252, -4.922, -6.625, 
>>>> -14.099, -13.264, 3.000>>
>>> Further I found a bit strange scores in the output from single-thread run.
>>>> BEST TRANSLATION: further , the plate supporting member 23 , 
>>>> ランバーサポートプレート|UNK|UNK|UNK 22 in the longitudinal direction end portion of 
>>>> the sheet , and the position adjustment of of the present perform , . . . 
>>>> , member (L) to with a the cooperation 
>>>> [11111111111111111111111111111111111111]  
>>>> [total=46627944870416590547798387064832.000] <<-62.000, -41.000, -100.000, 
>>>> -2.709, -0.981, -5.427, -7.517, -3.445, -3.222, 
>>>> 155409058250575256304156525199360.000, 17418203209007577149166583808.000, 
>>>> -214.441, -62.693, -86.992, -62.601, -70.820, 17.998>>
>>> Do anyone also face that problem?
>>> 
>>> Best,
>>> Katsuhito
>>> --
>>> Katsuhito Sudoh
>>> NTT Communication Science Laboratories, Japan
>>> [email protected]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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


_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to