Thank you very much Rico, I'll give a try to the other options that you
mention.
On May 22, 2015 6:31 PM, Rico Sennrich rico.sennr...@gmx.ch wrote:
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
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
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
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
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
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
