Moses-support Digest, Vol 98, Issue 50

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: bjam level of parallelism for various moses binaries
(Kenneth Heafield)
2. Re: Train tree-to-tree model fail to generate right rules
(Rico Sennrich)


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

Message: 1
Date: Fri, 19 Dec 2014 10:38:07 -0500
From: Kenneth Heafield <moses@kheafield.com>
Subject: Re: [Moses-support] bjam level of parallelism for various
moses binaries
To: moses-support@mit.edu
Message-ID: <5494465F.5020901@kheafield.com>
Content-Type: text/plain; charset=windows-1252

There's nothing wrong in theory with having a catch-all moses lib that
internal programs do not depend on.

Kenneth

On 12/19/14 09:50, Christian Hardmeier wrote:
> Doing so has the potential to make linking external code to moses a nightmare because of library interdependencies, unless it's really well designed.
>
> Just a word of warning. :)
> Christian
>
> On Dec 19, 2014, at 3:39 PM, Hieu Hoang wrote:
>
>> It seems like a lot of the programs now depend on the moses lib so any change to it trigger mass relinking.
>>
>> It may be that we should separate out the functionality into different lib files.
>>
>> Sent while bumping into things
>>
>> On 19 Dec 2014 20:00, "Hieu Hoang" <Hieu.Hoang@ed.ac.uk> wrote:
>> What's the solution? Sort out header files? Ditch bjam?
>>
>> Sent while bumping into things
>>
>> On 19 Dec 2014 19:10, "Kenneth Heafield" <moses@kheafield.com> wrote:
>> You can run bjam and name a specific target. It's also fair to complain
>> that these executables draw in way more dependencies than they need,
>> which is slowing down compilation.
>>
>> Kenneth
>>
>> On 12/19/2014 08:30 AM, Prashant Mathur wrote:
>>> Adding to this..
>>> Can we have a mode for selective compilation for development purpose?
>>> For building moses executable, we don't need these relax-parse,
>>> consolidate-parse, extract .. and so on..
>>>
>>> On Fri, Dec 19, 2014 at 1:54 PM, Martin Li?ka <marxin.liska@gmail.com
>>> <mailto:marxin.liska@gmail.com>> wrote:
>>>
>>> Hello.
>>>
>>> I've been just building Moses with enabled LTO (-flto) and compilation
>>> process runs for quite long time just in one thread:
>>>
>>> There're are many of:
>>>
>>> gcc.link
>>> phrase-extract/bin/gcc-5.0.0/release/debug-symbols-on/link-static/threading-multi/relax-parse
>>> gcc.link
>>> phrase-extract/bin/gcc-5.0.0/release/debug-symbols-on/link-static/threading-multi/consolidate-reverse
>>> phrase-extract/bin/gcc-5.0.0/release/debug-symbols-on/link-static/threading-multi/extract
>>>
>>> ...
>>>
>>> And my question is if there are any dependencies between these
>>> executables that potentially block parallel build?
>>>
>>> Thanks,
>>> Martin
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu <mailto: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
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>


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

Message: 2
Date: Fri, 19 Dec 2014 17:05:38 +0000 (UTC)
From: Rico Sennrich <rico.sennrich@gmx.ch>
Subject: Re: [Moses-support] Train tree-to-tree model fail to generate
right rules
To: moses-support@mit.edu
Message-ID: <loom.20141219T175749-920@post.gmane.org>
Content-Type: text/plain; charset=us-ascii

Steven Huang <d98922047@...> writes:

>
> Hi,
> I am trying to train an English to Chinese tree-to-tree model with
manually generated corpus. The translation is unacceptable. It seems that
the model doen't know reordering at all. So I look into the rule-table,
there is no useful rule in it (see the attached file "rule-table.gz").

Hi Steven,

the default rule extraction parameters are only suitable for unlabelled
hierarchical models. For syntactic models, you probably want to set (at
least) these parameters:

-extract-options="--NonTermConsecSource --MinHoleSource 1"

this allows nonterminals that span only a single word (MinHoleSource 1) and
consecutive nonterminals (NonTermConsecSource). If you use the latter, you
might want to look into scope-3 pruning of your grammar to keep decoding
complexity low: http://www.aclweb.org/anthology/D10-1063.pdf

some other options to consider:

--MinWords 0 (to allow non-lexical rules)
--MaxNonTerm SIZE (to allow SIZE nonterminals per rule (default 2))

I haven't built tree-to-tree systems myself, so I can't say which settings
work best.

best wishes,
Rico



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

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


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

Tweet