Moses-support Digest, Vol 98, Issue 39

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: Moses machine translation performance tuning
(Kenneth Heafield)
2. Re: Moses machine translation performance tuning
(Kenneth Heafield)
3. Re: Git sparse-checkout (Hieu Hoang)
4. Re: Problem when compiling Moses (Hieu Hoang)
5. Re: Tree-to-Tree rule table column definition (Hieu Hoang)


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

Message: 1
Date: Fri, 12 Dec 2014 19:57:47 -0500
From: Kenneth Heafield <moses@kheafield.com>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: moses-support@mit.edu
Message-ID: <548B8F0B.2090903@kheafield.com>
Content-Type: text/plain; charset=utf-8

Don't recompute the future cost each time. Compute the delta.

https://github.com/kpu/mtplz/blob/master/decode/future.hh

On 12/12/2014 10:15 AM, Martin Li?ka wrote:
> On 12 December 2014 at 15:54, Barry Haddow <bhaddow@staffmail.ed.ac.uk> wrote:
>> Hi Martin
>>
>> Interesting work - thanks for sharing.
>>
>> I was just curious about this comment:
>>
>>> Moses::Hypothesis::EvaluateWhenApplied method is dominated by calculation
>>> of bit intervals. More precisely, for a given set represented in bits:
>>> 010011, we would like identify consecutive zero chunks: <3-4> and <6-6>. I
>>> am not familiar with any vector instruction solution which can help
>>
>> Where is the calculation of bit intervals done? If this is a big issue,
>> could they be precalculated somehow? Bit vectors start off as all zeroes,
>> then each time a bit is flipped, the a zero chunk is split,
>>
>> cheers - Barry
>
> Hello Barry.
>
> This calculation is processed in
> https://github.com/moses-smt/mosesdecoder/blob/master/moses/SquareMatrix.cpp#L40,
> Mentioned function takes words bitmap, calculates consecutive zero
> chunks and calls GetScore for each of these chunks.
>
> I am not sure it can beneficial to have a list of these chunks
> maintained after each flip operation.
>
> Martin
>
>
>>
>>
>> On 12/12/14 12:45, Martin Li?ka wrote:
>>>
>>> Hello.
>>>
>>> As part of my SUSE Hackweek project ([1]), I've spent couple of days
>>> playing with Moses performance tuning. I cooperated with Ale? and our
>>> effort produced two patches that have been just merged to mainline. If
>>> you are interested in more details, please visit my blog post: [2].
>>> I would be really happy if my blog post would become a kick-off for
>>> further performance tuning.
>>>
>>> Thanks,
>>> Martin Li?ka,
>>> SUSE Labs
>>>
>>> [1] https://hackweek.suse.com/11/projects/284
>>> [2] http://marxin.github.io/posts/moses-performance-tuning/
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>


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

Message: 2
Date: Fri, 12 Dec 2014 20:12:51 -0500
From: Kenneth Heafield <moses@kheafield.com>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: moses-support@mit.edu
Message-ID: <548B9293.9070409@kheafield.com>
Content-Type: text/plain; charset=utf-8

That reduces it to searches left and right for the spans of zeros in
which the phrase occurs. After some shift and a mask, each of these
reduces to finding the first 1 in a 64-bit int, which can be done in one
instruction on Intel and has a gcc builtin.
http://en.wikipedia.org/wiki/Find_first_set

Kenneth

On 12/12/2014 07:57 PM, Kenneth Heafield wrote:
> Don't recompute the future cost each time. Compute the delta.
>
> https://github.com/kpu/mtplz/blob/master/decode/future.hh
>
> On 12/12/2014 10:15 AM, Martin Li?ka wrote:
>> On 12 December 2014 at 15:54, Barry Haddow <bhaddow@staffmail.ed.ac.uk> wrote:
>>> Hi Martin
>>>
>>> Interesting work - thanks for sharing.
>>>
>>> I was just curious about this comment:
>>>
>>>> Moses::Hypothesis::EvaluateWhenApplied method is dominated by calculation
>>>> of bit intervals. More precisely, for a given set represented in bits:
>>>> 010011, we would like identify consecutive zero chunks: <3-4> and <6-6>. I
>>>> am not familiar with any vector instruction solution which can help
>>>
>>> Where is the calculation of bit intervals done? If this is a big issue,
>>> could they be precalculated somehow? Bit vectors start off as all zeroes,
>>> then each time a bit is flipped, the a zero chunk is split,
>>>
>>> cheers - Barry
>>
>> Hello Barry.
>>
>> This calculation is processed in
>> https://github.com/moses-smt/mosesdecoder/blob/master/moses/SquareMatrix.cpp#L40,
>> Mentioned function takes words bitmap, calculates consecutive zero
>> chunks and calls GetScore for each of these chunks.
>>
>> I am not sure it can beneficial to have a list of these chunks
>> maintained after each flip operation.
>>
>> Martin
>>
>>
>>>
>>>
>>> On 12/12/14 12:45, Martin Li?ka wrote:
>>>>
>>>> Hello.
>>>>
>>>> As part of my SUSE Hackweek project ([1]), I've spent couple of days
>>>> playing with Moses performance tuning. I cooperated with Ale? and our
>>>> effort produced two patches that have been just merged to mainline. If
>>>> you are interested in more details, please visit my blog post: [2].
>>>> I would be really happy if my blog post would become a kick-off for
>>>> further performance tuning.
>>>>
>>>> Thanks,
>>>> Martin Li?ka,
>>>> SUSE Labs
>>>>
>>>> [1] https://hackweek.suse.com/11/projects/284
>>>> [2] http://marxin.github.io/posts/moses-performance-tuning/
>>>>
>>>> _______________________________________________
>>>> Moses-support mailing list
>>>> Moses-support@mit.edu
>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>>
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>


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

Message: 3
Date: Sat, 13 Dec 2014 10:41:14 +0000
From: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Subject: Re: [Moses-support] Git sparse-checkout
To: Guchun Zhang <gzhang@alphacrc.com>
Cc: "moses-support@MIT.EDU" <moses-support@mit.edu>
Message-ID:
<CAEKMkbgpTVGePGmbv3J4W1UzfYBXZY_80cc07NY-N=MPfou2vA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

what do we need to do in the repository? Have you tried doing sparse
checkout? let me know how it goes

On 12 December 2014 at 11:51, Guchun Zhang <gzhang@alphacrc.com> wrote:
>
> Hi,
>
> I just wonder whether git's sparse-checkout has been enabled in Moses'
> Repository.
>
> Regards,
> Guchun
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>

--
Hieu Hoang
Research Associate
University of Edinburgh
http://www.hoang.co.uk/hieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20141213/de0d379c/attachment-0001.htm

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

Message: 4
Date: Sat, 13 Dec 2014 10:44:58 +0000
From: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Subject: Re: [Moses-support] Problem when compiling Moses
To: Abdelfetah Boumerdas <aa_boumerdas@esi.dz>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAEKMkbhdG+nLta2nah-4z94MzU-Z6b3+SQihJm4k3RcpRY+Vig@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

the build.log file has been cut somehow. Are you sure you boost library is
in



*~/workspace/temp/boost_1_55_0?*


*Please follow the instruction on here to compile boost before you compile
moses: http://www.statmt.org/moses/?n=Development.GetStarted
<http://www.statmt.org/moses/?n=Development.GetStarted>*

On 12 December 2014 at 11:30, Abdelfetah Boumerdas <aa_boumerdas@esi.dz>
wrote:
>
> Hello
> I'm trying to compile Moses to do some tests on machine translation, i am
> following the manual i downloaded from the website, i installed g++ and
> boost, i downloaded moses from github but when i execute this command (to
> compile moses):
> .
> */bjam --with-boost=~/workspace/temp/boost_1_55_0 -j8 *
> and replace the path with the path where I've installed boost i get an
> error and the process stops.
>
> the log file is attached to this mail. Can you please tell me what's the
> error and how to resolve it.
>
>
> Thanks in advance.
> --
> BOUMERDAS Abdelfetah
> 5?me Ann?e Option Syst?mes Informatiques (SIQ)
> Ecole nationale Sup?rieure d'Informatique ESI (ex INI)
> BP 68 M Oued Smar 16309 - ALGER
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>

--
Hieu Hoang
Research Associate
University of Edinburgh
http://www.hoang.co.uk/hieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20141213/c1d3754a/attachment-0001.htm

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

Message: 5
Date: Sat, 13 Dec 2014 10:50:23 +0000
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] Tree-to-Tree rule table column definition
To: moses-support@mit.edu, lobichai@hotmail.com
Message-ID: <548C19EF.9090609@gmail.com>
Content-Type: text/plain; charset="utf-8"


On 11/12/14 08:52, Ben Ao wrote:
>
> Dear all,
>
> I was trained the tree-to-tree rule-table from Chinese to English.
>
> The command I used to train the model is:
>
> ~/mosesdecoder/scripts/training/train-model.perl \
>
> -external-bin-dir /share/apps/moses/gcc/giza-bin-dir \
>
> -root-dir zct2t_en \
>
> -corpus test.10.moses -f cn -e en \
>
> -alignment grow-diag-final-and -source-syntax -target-syntax
> -glue-grammar \
>
> -lm 0:3:/home/ben/data/zc.blm.en:1
>
> However, I find out the rule-table is very strange. Such as:
>
> Brunel ? ?[VP][VP] ?[IP] ||| now brunel may have [VP][VP] , [TOP]
> ||| 0.499999 7.48437e-05 0.499999 0.0159349 2.718 ||| 0-0 0-1 1-2 1-3
> 2-4 3-5 ||| 0.166667 0.166667 0.0833333
>
> CA? ?[VP][VBD] ?[IP] ||| ca : i [VP][VBD] . [TOP] ||| 0.5 0.15398
> 0.5 0.0413438 2.718 ||| 0-0 0-1 1-2 2-3 3-4 ||| 0.222222 0.222222 0.111111
>
> Question 1: There contain 5 probabilities in the middle:
>
> 0.499999 7.48437e-05 0.499999 0.0159349 2.718
>
> 0.5 0.15398 0.5 0.0413438 2.718
>
> The last part ?2.718? is same in all rules of the rule-table, but what
> it means?
>
all probabilities are transformed by the log() function before being
used by the decoder. log(2.718)=1.
It's really just a phrase-penalty, not a probability.

You are using a slightly old version of moses. In the current version,
the phrase-table does not have this number, it has been moved to its own
feature function
>
> Question 2: What is meaning for the last part in the rule?
>
> 0.166667 0.166667 0.0833333
>
> 0.222222 0.222222 0.111111
>
> It look like some probabilities, but what it means?
>
they are count, for debugging information. They don't affect decoding
>
> I worked on this problem for a few weeks, and no idea of the
> definition for the rule-table generated by tree-to-tree training.
>
> Many and many thanks for solving those problem!!
>
> Regards,
>
> Ben
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20141213/a340f550/attachment.htm

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

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


End of Moses-support Digest, Vol 98, Issue 39
*********************************************

Tweet