Moses-support Digest, Vol 103, Issue 49

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 (Hieu Hoang)
2. Re: keep some features fixed when tuning (Rico Sennrich)
3. Re: Stripping carriage returns in FilePiece? (Kenneth Heafield)
4. Re: Stripping carriage returns in FilePiece? (Jeroen Vermeulen)


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

Message: 1
Date: Wed, 20 May 2015 15:45:53 +0400
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] keep some features fixed when tuning
To: Matthias Huck <mhuck@inf.ed.ac.uk>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAEKMkbh-T9kGaMptncVOx_Sp4vMAbmTLDG_0mpO18gC_RY9fbA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

you can also put this into the EMS:

[TUNING]
decoding-settings = "-feature-overwrite \"TranslationModel0
tuneable=false\" \"AnotherFeatureName tuneable=fase\" "

I forget if you have to escape the quotes. You have to escape it in
[TUNING], but not in [EVALUATION]. Or may the other way round

Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

On 20 May 2015 at 15:39, Matthias Huck <mhuck@inf.ed.ac.uk> wrote:

> Hi Vito,
>
> tuneable=false should work.
>
> However, in case you use the EMS to run experiments, there's a pitfall:
> If a filtered phrase table for tuning exists from a previous
> experimental run, then the EMS will typically apply the filter and
> replace the line for the phrase table feature function in your moses.ini
> by the respective line from the filtered directory. In case the previous
> run didn't have tuneable=false, this will be dropped. You can easily
> check this and manually edit the filtered moses.ini in the tuning
> directory. A filtered moses.ini can be specified in the EMS config:
>
> [TUNING]
> filtered-config = $working-dir/tuning/moses.filtered.ini.10
>
> tuneable=false will keep all the score components of a feature function
> at their initial values. If you need something similar for individual
> components only, please have a look at this:
> https://www.mail-archive.com/moses-support@mit.edu/msg11653.html
>
> Cheers,
> Matthias
>
>
> On Wed, 2015-05-20 at 10:12 +0200, Vito Mandorino wrote:
> > Dear all,
> >
> > is it possible when tuning to tell Moses to constrain the value of a
> subset
> > of the features to some fixed, given-in-advance values ?
> > I would like to do that because I'm dealing with a very small tuning set,
> > and I think that reducing the number of tuneable features will prevent
> > overfitting.
> > I have tried two approaches so far but results were not as expected (or
> > desired):
> > - add tuneable=false to the concerned features in the moses.ini
> > - add
> > --decoder-flags "-weight-overwrite 'LM0= 0.086 WordPenalty0= -0.021
> > PhrasePenalty0= 0.022 Distortion0= 0.3 TranslationModel1= 0.04 -0.01 0.25
> > 0.19'"
> > to the mert-moses.pl command.
> >
> >
> > Best regards,
> >
> > Vito Mandorino
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150520/f3435b73/attachment-0001.htm

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

Message: 2
Date: Wed, 20 May 2015 12:38:30 +0000 (UTC)
From: Rico Sennrich <rico.sennrich@gmx.ch>
Subject: Re: [Moses-support] keep some features fixed when tuning
To: moses-support@mit.edu
Message-ID: <loom.20150520T143137-647@post.gmane.org>
Content-Type: text/plain; charset=us-ascii

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



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

Message: 3
Date: Wed, 20 May 2015 11:55:54 -0400
From: Kenneth Heafield <moses@kheafield.com>
Subject: Re: [Moses-support] Stripping carriage returns in FilePiece?
To: moses-support@mit.edu
Message-ID: <555CAE8A.5060303@kheafield.com>
Content-Type: text/plain; charset=windows-1252

On 05/19/2015 11:50 PM, Jeroen Vermeulen wrote:
>
>>>> Also, how would you feel if I changed it to be FakeIFStream with
>>>> operator>> extraction, at least for integer/float types?
>>>
>>> Sorry, I haven't looked into FakeIFStream at all yet, and I may not
>>> fully understand the question.
>>
>> It doesn't exist yet. I am contemplating refactoring FilePiece to have
>> operator>> and renaming it to FakeIFStream.
>
> Any ideas on how you would map the different ways of reading into a
> stream-style API? By adding manipulators? One thing I don't like about
> those is that they require you to track and understand more stream state
> to understand exactly what a piece of code does.
>
> I do think turning the class into a stream will make code easier to
> follow generally. On the flip side, it may make it harder to find out
> which function is being called where. That matters when debugging the
> finer points, as I've been doing with this carriage-return issue.

Let's take this off-list. I don't like manipulators either. Just
thinking it would have getline and operator>> for built-in types. And
other methods for more specialized types of reading.


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

Message: 4
Date: Wed, 20 May 2015 23:17:05 +0700
From: Jeroen Vermeulen <jtv@precisiontranslationtools.com>
Subject: Re: [Moses-support] Stripping carriage returns in FilePiece?
To: Kenneth Heafield <moses@kheafield.com>, moses-support@mit.edu
Message-ID:
<026C623F-02F0-4C41-82F8-463848CCBD90@precisiontranslationtools.com>
Content-Type: text/plain; charset=UTF-8

On May 20, 2015 10:55:54 PM GMT+07:00, Kenneth Heafield <moses@kheafield.com> wrote:
>On 05/19/2015 11:50 PM, Jeroen Vermeulen wrote:
>>
>>>>> Also, how would you feel if I changed it to be FakeIFStream with
>>>>> operator>> extraction, at least for integer/float types?
>>>>
>>>> Sorry, I haven't looked into FakeIFStream at all yet, and I may not
>>>> fully understand the question.
>>>
>>> It doesn't exist yet. I am contemplating refactoring FilePiece to
>have
>>> operator>> and renaming it to FakeIFStream.
>>
>> Any ideas on how you would map the different ways of reading into a
>> stream-style API? By adding manipulators? One thing I don't like
>about
>> those is that they require you to track and understand more stream
>state
>> to understand exactly what a piece of code does.
>>
>> I do think turning the class into a stream will make code easier to
>> follow generally. On the flip side, it may make it harder to find
>out
>> which function is being called where. That matters when debugging
>the
>> finer points, as I've been doing with this carriage-return issue.
>
>Let's take this off-list. I don't like manipulators either. Just
>thinking it would have getline and operator>> for built-in types. And
>other methods for more specialized types of reading.
>_______________________________________________
>Moses-support mailing list
>Moses-support@mit.edu
>http://mailman.mit.edu/mailman/listinfo/moses-support

Sure. So the main thing is the field conversions? That does sound very stream-like.


Jeroen


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

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


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

Tweet