Moses-support Digest, Vol 103, Issue 47

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: Stripping carriage returns in FilePiece? (Jeroen Vermeulen)
2. keep some features fixed when tuning (Vito Mandorino)
3. Factored models and xml-input (Standa K)
4. Re: Sentence-level features (Hieu Hoang)


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

Message: 1
Date: Wed, 20 May 2015 10:50:57 +0700
From: Jeroen Vermeulen <jtv@precisiontranslationtools.com>
Subject: Re: [Moses-support] Stripping carriage returns in FilePiece?
To: moses-support@mit.edu
Message-ID: <555C04A1.8060504@precisiontranslationtools.com>
Content-Type: text/plain; charset=windows-1252

On 19/05/15 22:09, Kenneth Heafield wrote:

>>> There are non-traditional uses like ReadLine('\0') to read
>>> null-delimited tokens.
>>
>> While exploring this change I didn't find a single use of that parameter
>> in the Moses source tree!
>
> It's in some new code in KenLM master that I wouldn't feel bad about
> changing.

No need ? just pass "false" for the strip_cr parameter.


>>> 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.


Jeroen


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

Message: 2
Date: Wed, 20 May 2015 10:12:36 +0200
From: Vito Mandorino <vito.mandorino@linguacustodia.com>
Subject: [Moses-support] keep some features fixed when tuning
To: moses-support <moses-support@mit.edu>
Message-ID:
<CA+8mSmGqu1L8bgnB79VNSaQObK6eP9kVm9xXMM=zE7GGvQ9TKQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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

--
*M**. Vito MANDORINO -- Chief Scientist*


[image: 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
<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/20150520/eb5ea4c0/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4421 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20150520/eb5ea4c0/attachment-0001.jpg

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

Message: 3
Date: Wed, 20 May 2015 09:19:09 +0000 (UTC)
From: Standa K <standa.kurik@gmail.com>
Subject: [Moses-support] Factored models and xml-input
To: moses-support@mit.edu
Message-ID: <loom.20150520T111546-456@post.gmane.org>
Content-Type: text/plain; charset=us-ascii

Hello,

may I ask if there is a plan to add the support for xml-input to factored
models in foreseeable future or is this not a priority at all?

If it is not, could someone perhaps point me to the places in code which
need to be modified? I tried finding these myself, but got lost pretty
soon.

Thank you.

Best regards
Standa Kurik



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

Message: 4
Date: Wed, 20 May 2015 13:53:09 +0400
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] Sentence-level features
To: Varvara Logacheva <varvara.logacheva@gmail.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAEKMkbgo2H216dPz=S=ghKtGV1q2jCx6i8z6OqPDc93amdBwqg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

if you mean a featiure function that is given the hypothesis that translate
the whole sentence - yes. But the FF is also given partial hypos too, you
can just ignore them

if you want multipass decoding - no

if you want n-best reranking - no, but it's easy to implement

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

On 19 May 2015 at 22:45, Varvara Logacheva <varvara.logacheva@gmail.com>
wrote:

> Dear Moses users,
>
> could you please tell if Moses has any mechanism of adding sentence-level
> features?
> I mean features that can be evaluated only when the whole hypothesis is
> generated.
>
> Thank you.
>
> Best,
>
> Varvara.
>
> _______________________________________________
> 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/32fd0ca7/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 47
**********************************************

Tweet