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: Major bug found in Moses (Read, James C)
2. Re: Major bug found in Moses (amittai axelrod)
3. Re: Moses-support Digest, Vol 104, Issue 56 (Tom Hoar)
4. Re: Major bug found in Moses (Marcin Junczys-Dowmunt)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Jun 2015 16:51:18 +0000
From: "Read, James C" <jcread@essex.ac.uk>
Subject: Re: [Moses-support] Major bug found in Moses
To: Lane Schwartz <dowobeha@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Philipp Koehn
<phi@jhu.edu>
Message-ID:
<DB3PR06MB07130F784C13F071284AF57C85A40@DB3PR06MB0713.eurprd06.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
P.S. Have a good weekend everybody. Be back in action in a couple of days.
James
________________________________
From: Read, James C
Sent: Friday, June 19, 2015 7:49 PM
To: Lane Schwartz
Cc: Philipp Koehn; Burger, John D.; moses-support@mit.edu
Subject: Re: [Moses-support] Major bug found in Moses
So, all I did was filter out the less likely phrase pairs and the BLEU score shot up. Was that such a stroke of genius? Was that not blindingly obvious?
Your telling me that redesigning the search algorithm to prefer higher scoring phrase pairs is all we need to do to get a best paper at ACL?
James
________________________________
From: Lane Schwartz <dowobeha@gmail.com>
Sent: Friday, June 19, 2015 7:40 PM
To: Read, James C
Cc: Philipp Koehn; Burger, John D.; moses-support@mit.edu
Subject: Re: [Moses-support] Major bug found in Moses
On Fri, Jun 19, 2015 at 11:28 AM, Read, James C <jcread@essex.ac.uk<mailto:jcread@essex.ac.uk>> wrote:
What I take issue with is the en-masse denial that there is a problem with the system if it behaves in such a way with no LM + no pruning and/or tuning.
There is no mass denial taking place.
Regardless of whether or not you tune, the decoder will do its best to find translations with the highest model score. That is the expected behavior.
What I have tried to tell you, and what other people have tried to tell you, is that translations with high model scores are not necessarily good translations.
We all want our models to be such that high model scores correspond to good translations, and that low model scores correspond with bad translations. But unfortunately, our models do not innately have this characteristic. We all know this. We also know a good way to deal with this shortcoming, namely tuning. Tuning is the process by which we attempt to ensure that high model scores correspond to high quality translations, and that low model scores correspond to low quality translations.
If you can design models that naturally correspond with translation quality without tuning, that's great. If you can do that, you've got a great shot at winning a Best Paper award at ACL.
In the meantime, you may want to consider an apology for your rude behavior and unprofessional attitude.
Goodbye.
Lane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150619/8a05b884/attachment-0001.htm
------------------------------
Message: 2
Date: Fri, 19 Jun 2015 12:52:17 -0400
From: amittai axelrod <amittai@umiacs.umd.edu>
Subject: Re: [Moses-support] Major bug found in Moses
To: "Read, James C" <jcread@essex.ac.uk>, Lane Schwartz
<dowobeha@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Philipp Koehn
<phi@jhu.edu>
Message-ID: <558448C1.3070504@umiacs.umd.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
if we don't understand the problem, how can we possibly fix it?
all the relevant code is open source. go for it!
~amittai
On 6/19/15 12:49, Read, James C wrote:
> So, all I did was filter out the less likely phrase pairs and the BLEU
> score shot up. Was that such a stroke of genius? Was that not blindingly
> obvious?
>
>
> Your telling me that redesigning the search algorithm to prefer higher
> scoring phrase pairs is all we need to do to get a best paper at ACL?
>
>
> James
>
>
>
> ------------------------------------------------------------------------
> *From:* Lane Schwartz <dowobeha@gmail.com>
> *Sent:* Friday, June 19, 2015 7:40 PM
> *To:* Read, James C
> *Cc:* Philipp Koehn; Burger, John D.; moses-support@mit.edu
> *Subject:* Re: [Moses-support] Major bug found in Moses
> On Fri, Jun 19, 2015 at 11:28 AM, Read, James C <jcread@essex.ac.uk
> <mailto:jcread@essex.ac.uk>> wrote:
>
> What I take issue with is the en-masse denial that there is a
> problem with the system if it behaves in such a way with no LM + no
> pruning and/or tuning.
>
>
> There is no mass denial taking place.
>
> Regardless of whether or not you tune, the decoder will do its best to
> find translations with the highest model score. That is the expected
> behavior.
>
> What I have tried to tell you, and what other people have tried to tell
> you, is that translations with high model scores are not necessarily
> good translations.
>
> We all want our models to be such that high model scores correspond to
> good translations, and that low model scores correspond with bad
> translations. But unfortunately, our models do not innately have this
> characteristic. We all know this. We also know a good way to deal with
> this shortcoming, namely tuning. Tuning is the process by which we
> attempt to ensure that high model scores correspond to high quality
> translations, and that low model scores correspond to low quality
> translations.
>
> If you can design models that naturally correspond with translation
> quality without tuning, that's great. If you can do that, you've got a
> great shot at winning a Best Paper award at ACL.
>
> In the meantime, you may want to consider an apology for your rude
> behavior and unprofessional attitude.
>
> Goodbye.
> Lane
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
------------------------------
Message: 3
Date: Fri, 19 Jun 2015 23:58:09 +0700
From: Tom Hoar <tahoar@precisiontranslationtools.com>
Subject: Re: [Moses-support] Moses-support Digest, Vol 104, Issue 56
To: moses-support@mit.edu
Message-ID: <55844A21.9060405@precisiontranslationtools.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Lane, thank you. You picked up on the "frequent mentions of investors"
as I did. Not only is it "non sequitur" on this list, it's simply bad
form and out of line.
James: PTTools is (through Jeroen and I) an active commercial
participant on this list and there are others. Our business dealings are
of no concern to the advancement of the science this list supports. Nor
have I see others expose their business dealings here. Where PTTools'
business might affect the list, we have done our best to work with the
team to lighten their load. If all your ranting about broken moses is
about justifying your claims to investors, you and your attitude are way
out of line! If I were to step out of line like this, I would hope
someone here would call me on it and finally sensor me if I continue
down that path.
Tom
On 6/19/2015 11:16 PM, moses-support-request@mit.edu wrote:
> Date: Fri, 19 Jun 2015 10:10:31 -0500
> From: Lane Schwartz <dowobeha@gmail.com>
> Subject: Re: [Moses-support] Major bug found in Moses
> To: "Read, James C" <jcread@essex.ac.uk>
> Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Philipp Koehn
> <phi@jhu.edu>
> Message-ID:
> <CABv3vZm+Y-TFx77O_o5Gy3_oHdTZVkDs0FQJ9A_d9rk2HeF2Tg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> James,
>
> > 1) Acknowledging that the search algorithm performs poorly with no LM,
> > tuning or pruning despite the fact the search space clearly contains high
> > quality translations
> >
> Yes. We all acknowledge this. If you have a better technique, that's great.
> Show that it's better. Your paper does not do so.
>
> 2) to a public display of en-masse reluctance to acknowledge that such is
> > an undesirable quality of the system
> >
> Yes, this is undesirable. If you have a better technique, that's great.
> Show that it's better. Your paper does not do so.
>
>
> > 3) to resorting to censorship not only in the literature but also on a
> > public mailing list rather than acknowledge point 2.
> >
> No one is trying to censor you in the literature. You wrote a paper that
> got rejected. Lots of papers get rejected. Lots of GOOD papers get
> rejected. The fact that yours got rejected does not mean that you're being
> censored.
>
> No one is trying to censor you on this list. We are simply requesting that
> you conduct yourself like a well-mannered adult engaged in scientific
> research.
>
>
> By the way, your frequent mentions of investors are very much a non
> sequitur. You may be looking for investors, and that's fine if you are. You
> may want to keep in mind that not everyone is. Many of us are interested in
> this as a field of scientific enquiry.
------------------------------
Message: 4
Date: Fri, 19 Jun 2015 19:21:45 +0200
From: Marcin Junczys-Dowmunt <junczys@amu.edu.pl>
Subject: Re: [Moses-support] Major bug found in Moses
To: moses-support@mit.edu
Message-ID: <55844FA9.80801@amu.edu.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On that interesting idea that moses should be naturally good at
translating things, just for general considerations.
Since some said this thread has educational value I would like to share
something that might not be obvious due to the SMT-biased posts here.
Moses is also the _leading_ tool for automatic grammatical error
correction (GEC) right now. The first and third system of the CoNLL
shared task 2014 were based on Moses. By now I have results that surpass
the CoNLL results by far by adding some specialized features to Moses
(which thanks to Hieu is very easy).
It even gets good results for GEC when you do crazy things like
inverting the TM (so it should actually make the input worse) provided
you tune on the correct metric and for the correct task. The interaction
of all the other features after tuning makes that possible.
So, if anything, Moses is just a very flexible text-rewriting tool.
Tuning (and data) turns into a translator, GEC tool, POS-tagger,
Chunker, Semantic Tagger etc.
On 19.06.2015 18:40, Lane Schwartz wrote:
> On Fri, Jun 19, 2015 at 11:28 AM, Read, James C <jcread@essex.ac.uk
> <mailto:jcread@essex.ac.uk>> wrote:
>
> What I take issue with is the en-masse denial that there is a
> problem with the system if it behaves in such a way with no LM +
> no pruning and/or tuning.
>
>
> There is no mass denial taking place.
>
> Regardless of whether or not you tune, the decoder will do its best to
> find translations with the highest model score. That is the expected
> behavior.
>
> What I have tried to tell you, and what other people have tried to
> tell you, is that translations with high model scores are not
> necessarily good translations.
>
> We all want our models to be such that high model scores correspond to
> good translations, and that low model scores correspond with bad
> translations. But unfortunately, our models do not innately have this
> characteristic. We all know this. We also know a good way to deal with
> this shortcoming, namely tuning. Tuning is the process by which we
> attempt to ensure that high model scores correspond to high quality
> translations, and that low model scores correspond to low quality
> translations.
>
> If you can design models that naturally correspond with translation
> quality without tuning, that's great. If you can do that, you've got a
> great shot at winning a Best Paper award at ACL.
>
> In the meantime, you may want to consider an apology for your rude
> behavior and unprofessional attitude.
>
> Goodbye.
> Lane
>
>
>
> _______________________________________________
> 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
End of Moses-support Digest, Vol 104, Issue 59
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 104, Issue 59"
Post a Comment