Moses-support Digest, Vol 103, Issue 59

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: keep some features fixed when tuning (Rico Sennrich)
2. inc-giza Installation Issue - Incremental Training
(Bar?? G?vercin)


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

Message: 1
Date: Fri, 22 May 2015 17:31:00 +0100
From: Rico Sennrich <rico.sennrich@gmx.ch>
Subject: Re: [Moses-support] keep some features fixed when tuning
To: Vito Mandorino <vito.mandorino@linguacustodia.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID: <555F59C4.9000601@gmx.ch>
Content-Type: text/plain; charset="utf-8"

Hi Vito

Yes, that's basically what happens, and you're right that
"tuneable=false" can be harmful to MERT - hence my warning. I've heard
of people trying to keep the weights of a language model fixed through
it, and this didn't work at all.

MERT (but not MIRA) also supports the option "-o" to define which
features to optimize, and mert-moses.perl accepts the option
"--activate-features" to do the same (it then passes the list of
features to MERT). This may be more suitable for some cases.

Code contributions for a better way of having fixed weights (that also
works for PRO and MIRA) are welcome.

best wishes,
Rico

On 22.05.2015 17:07, Vito Mandorino wrote:
> Thank you all. Can you explain further what does it mean that MERT
> won't know that the feature exists? Does that mean that the tuneable
> feature weights are optimized assuming that all non-tuneable feature
> weights are equal to zero?
> In fact, in my understanding this should lead to a dramatic decrease
> of the score Bleu on the tuning set, but this is not what I ended up
> with in my tests, at least in some cases (decrease of just 0.19 Bleu
> when adding tuneable=false to PhrasePenalty and Distortion on a tuning
> set constituted by 574 segments).
>
> Vito M.
>
> 2015-05-20 14:38 GMT+02:00 Rico Sennrich <rico.sennrich@gmx.ch
> <mailto:rico.sennrich@gmx.ch>>:
>
> Matthias Huck <mhuck@...> writes:
>
> >
> > Hi Vito,
> >
> > tuneable=false should work.
>
> Just my usual caveat:
>
> if you use 'tuneable=false', the feature score(s) won't be
> reported to the n-best list, and MERT/MIRA/PRO won't even know
> that the
> feature exists. This is appropriate in some cases (keeping a
> feature weight
> at 0, or giving a high penalty to some glue rules to ensure that
> they are
> only used if no translation is possible without them), but in
> other cases,
> hiding important features causes the optimizer to search the wrong
> space.
>
> best wishes,
> Rico
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu <mailto:Moses-support@mit.edu>
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
>
>
> --
> *M**. Vito MANDORINO -- Chief Scientist*
>
> Description : Description : lingua_custodia_final full logo
>
> */The Translation Trustee/*
>
> *1, Place Charles de Gaulle, **78180 Montigny-le-Bretonneux*
>
> *Tel : +33 1 30 44 04 23 Mobile : +33 6 84 65 68 89*
>
> *Email :****vito.mandorino@linguacustodia.com
> <mailto:massinissa.ahmim@linguacustodia.com>***
>
> *Website :****www.linguacustodia.com
> <http://www.linguacustodia.com/> - www.thetranslationtrustee.com
> <http://www.thetranslationtrustee.com/>*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150522/6ef79f2f/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4421 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20150522/6ef79f2f/attachment-0001.jpg

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

Message: 2
Date: Fri, 22 May 2015 20:46:58 +0300
From: Bar?? G?vercin <bbrs.guvercin@gmail.com>
Subject: [Moses-support] inc-giza Installation Issue - Incremental
Training
To: moses-support@mit.edu
Message-ID: <555F6B92.6000204@gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

I'm trying to do incremental training with moses, training with multiple
translated files. I've been following steps at
http://www.statmt.org/moses/?n=Advanced.Incremental , but I'm stuck at
installing incremental giza ---- https://code.google.com/p/inc-giza-pp/ .

I've been passing through these steps :
svn checkout http://inc-giza-pp.googlecode.com/svn/trunk/
inc-giza-pp-read-only
cd inc-giza-pp-read-only
make

But it gives error like (after some successful compilations):
g++ -Wall -W -Wno-deprecated -O3 -DNDEBUG -DWORDINDEX_WITH_4_BYTE
-DBINARY_SEARCH_FOR_TTABLE optimized/Parameter.o optimized/myassert.o
optimized/Perplexity.o optimized/model1.o optimized/model2.o
optimized/model3.o optimized/getSentence.o optimized/TTables.o
optimized/ATables.o optimized/AlignTables.o optimized/main.o
optimized/NTables.o optimized/model2to3.o optimized/collCounts.o
optimized/alignment.o optimized/vocab.o optimized/MoveSwapMatrix.o
optimized/transpair_model3.o optimized/transpair_model5.o
optimized/transpair_model4.o optimized/utility.o optimized/parse.o
optimized/reports.o optimized/model3_viterbi.o
optimized/model3_viterbi_with_tricks.o optimized/Dictionary.o
optimized/model345-peg.o optimized/hmm.o optimized/HMMTables.o
optimized/ForwardBackward.o -L/usr/local/lib -lxmlrpc_server_abyss++
-lxmlrpc_server++ -lxmlrpc_server_abyss -lxmlrpc_server -lxmlrpc_abyss
-lpthread -lxmlrpc++ -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse
-lxmlrpc_xmltok -static -o GIZA++

/usr/local/lib/libxmlrpc_abyss.a(conf.o): In function `parseUser':
/home/hieu/xmlrpc-c-1.33.17/lib/abyss/src/conf.c:279: warning: Using
'getpwnam' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking
/usr/local/lib/libxmlrpc_util.a(lock_pthread.o): In function `destroy':
/home/hieu/xmlrpc-c-1.33.17/lib/libutil/lock_pthread.c:41: undefined
reference to `pthread_mutex_destroy'
/usr/local/lib/libxmlrpc_util.a(lock_pthread.o): In function
`xmlrpc_lock_create_pthread':
/home/hieu/xmlrpc-c-1.33.17/lib/libutil/lock_pthread.c:63: undefined
reference to `pthread_mutex_init'
collect2: error: ld returned 1 exit status
make[1]: *** [GIZA++] Error 1
make[1]: Leaving directory `/home/hieu/inc-giza-pp-read-only/GIZA++-v2'
make: *** [gizapp] Error 2

I've already installed xmlrpc-c-1.33.17 library, and I tried to change "
-lpthread "s order in Makefile at GIZA++2-v2 directory -with some hope-,
but it didn't work. My system is Ubuntu 14.04. Am I missing something ?

Thanks in advance.
Bar??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150522/e557963e/attachment.htm

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

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


End of Moses-support Digest, Vol 103, Issue 59
**********************************************

Tweet