Moses-support Digest, Vol 104, Issue 42

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 (Tom Hoar)
2. Re: c++11 support (Jeroen Vermeulen)
3. Re: Major bug found in Moses (Germ?n Sanchis-Trilles)


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

Message: 1
Date: Thu, 18 Jun 2015 07:50:37 +0700
From: Tom Hoar <tahoar@precisiontranslationtools.com>
Subject: Re: [Moses-support] Major bug found in Moses
To: moses-support@mit.edu
Message-ID: <558215DD.2020902@precisiontranslationtools.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Amittai, I understand your point about sounding "almost belligerently
confrontational." I also admire Jame's passion and the Moses team's
patience to walk through his logic. As a non-scientific reader, this is
the most educational exchange I've seen on this list for years. I'm
learning a lot. Thank you everyone.

James, as a non-scientific reader, let me say that Hieu's head bashing
to solve the same puzzle shows you're in good company. Yet, the Moses
"system" is defined, designed and works with two functionally different
pieces, i.e. the front-end and back-end. The front-end creates a (an
often wild) array of candidate hypotheses -- by design. Why is this
piece designed this way? Because the system design includes a back-end
that selects a final choice from amongst the candidates. The two halves
share a symbiotic relationship. Together, the pieces form a system with
a balance that can only be achieved by working together. In this
context, this is not a "bug" (major or minor) and the "system" is not
broken.

I submit, as others have suggested, that you have conceived and are
working with a new and different "system" that consists of two different
halves. Your front-end reduces table to a focused set. Your back-end
works much like today's translation table to select from the focused
set. Major advances sometimes come by challenging the status quo. We
have seen evidence here of both the challenge and the status quo.

So, although I can not "admit the system is broke," I encourage you to
advance your new system without trying to fix one that's not broken.

Tom


> Date: Wed, 17 Jun 2015 15:48:14 +0000
> From: "Read, James C"<jcread@essex.ac.uk>
> Subject: Re: [Moses-support] Major bug found in Moses
> To: Marcin Junczys-Dowmunt<junczys@amu.edu.pl>
> Cc:"moses-support@mit.edu" <moses-support@mit.edu>, "Arnold, Doug"<doug@essex.ac.uk>
> Message-ID:<DB3PR06MB0713ADF9AF14EE5D93EC5BC485A60@DB3PR06MB0713.eurprd06.prod.outlook.com>
> Content-Type: text/plain; charset="iso-8859-2"
>
> 1) So if I've understood you correctly you are saying we have a system that is purposefully designed to perform poorly with a disabled LM and this is the proof that the LM is the most fundamental part. Any attempt to prove otherwise by, e.g. filtering the phrase table to help the disfunctional search algorithm, does not constitute proof that the TM is the most fundamental component of the system and if designed correctly can perform just fine on its own but rather only evidence that the researcher is not using the system as intended (the intention being to break the TM to support the idea that the LM is the most fundamental part).
>
> 2) If you still feel that the LM is the most fundamental component I challenge you to disable the TM and perform LM only translations and see what kind of BLEU scores you get.
>
> In conclusion, I do hope that you don't feel that potential investors in MT systems lack the intelligence to see through these logical fallacies. Can we now just admit that the system is broke and get around to fixing it?
>
> James



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

Message: 2
Date: Thu, 18 Jun 2015 09:59:09 +0700
From: Jeroen Vermeulen <jtv@precisiontranslationtools.com>
Subject: Re: [Moses-support] c++11 support
To: Lane Schwartz <dowobeha@gmail.com>, Ulrich Germann
<ugermann@inf.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<50D71897-1268-4BD3-91AE-74EDD22828E3@precisiontranslationtools.com>
Content-Type: text/plain; charset="utf-8"

On June 18, 2015 4:50:46 AM GMT+07:00, Lane Schwartz <dowobeha@gmail.com> wrote:
>C++ is a legacy programming language, built on an even older legacy
>programming language.
>
>Programming good C++ code that is readable, maintainable, and
>memory-safe
>is possible, but it requires a high degree of technical competency and
>discipline.
>
>The C++11 standard (and even more so the C++14 standard) represents a
>good-faith attempt to bring (at least some) current programming
>language
>best practices into C++. It represents an attempt to make C++ at least
>pretend to be a modern programming language that is usable without
>intimate
>knowledge of the dark arts of memory management and 30-40 years of
>backward-compatible cruft.
>
>Personally, I don't think the standards go far enough. But they are
>least a
>major step in the right direction.
>
>Use of C++11 is not avante garde. It is a very sensible move that will
>make
>it easier for new users to contribute, and make it slightly harder for
>certain types of bugs to hide.
>
>Ubuntu LTS 12.04LTS ships with gcc 4.6.3, which fully supports most
>C++11
>features; if there are actual concrete concerns about using the few
>features that aren't implemented in a five-year-old compiler, fine. But
>just remember that same five-year-old compiler can handle most C++11
>features just fine - the main reason not to use them is inertia.
>
>Unfortunately, there does not yet exist a mature general purpose
>programming language that can replace C++ for all important use cases.
>I
>have some hope, with the development of new languages like Swift, Rust,
>and
>Go, but we're not there yet.
>
>Take a look at the standard. It's not adding crazy controversial new
>things. It's mainly making C++ slightly less like living in the the
>wild
>west, and a little bit like living in the 21st century, where compilers
>can
>do sensible things like infer types some of the time.
>
>
>On Wed, Jun 17, 2015 at 2:50 PM, Ulrich Germann
><ulrich.germann@gmail.com>
>wrote:
>
>> I'd strongly advise against being too avant garde. Moses has a large
>user
>> base, and many users are still using (or have to use) stable,
>run-off-the
>> mill linux installations that are a few years old yet still
>officially
>> supported. In my opinion, our reference architecture for core moses
>> functionality should be the oldest Ubuntu LTS version still under
>official
>> support, currently Ubuntu 12.04. I have to admit that I don't keep
>track
>> closely what's happening with C++, but for me gcc-4.6 plus the boost
>> libraries still does the trick. Why the rush to the latest and
>greatest?
>> What exactly is so broken that we need C++11 to fix it?
>>
>> - Uli
>>
>> On Tue, Jun 16, 2015 at 5:02 PM, Rico Sennrich <rico.sennrich@gmx.ch>
>> wrote:
>>
>>> Hi list,
>>>
>>> some code in mosesdecoder (oxlm, c++tokenizer) already requires
>c++11. To
>>> let people benefit from the usability and functionality improvements
>of
>>> c++11, it would be beneficial to allow the use of c++11 features in
>all of
>>> the code.
>>>
>>> before people start making big changes to the codebase, we should
>make
>>> sure
>>> that there are no good reasons against allowing c++11 features, such
>as
>>> lack
>>> of compiler support.
>>>
>>> I pushed a minimal commit (6c0f875) to test the waters. If this
>introduces
>>> bugs, or if users still rely on old compilers without c++11 support,
>>> please
>>> complain here.
>>>
>>> best wishes,
>>> Rico
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>>
>>
>>
>> --
>> Ulrich Germann
>> Senior Researcher
>> School of Informatics
>> University of Edinburgh
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
>--
>When a place gets crowded enough to require ID's, social collapse is
>not
>far away. It is time to go elsewhere. The best thing about space
>travel
>is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Moses-support mailing list
>Moses-support@mit.edu
>http://mailman.mit.edu/mailman/listinfo/moses-support

I agree. I'm not saying we have to rush this, but it's good to know that C++ is becoming a much easier language to use. The newer versions let you write code that is both faster and clearer at the same time.

C++11 adds lambdas, and replaces auto_ptr with something less error-prone. Move semantics let you design code more like you would in a garbage-collected language. C++14 adds a standard threading interface, which could eliminate some custom code and portability issues. It also lets you be a bit clearer about function overriding in inheritance. C++17 is expected to have a standard "string piece" class called string view. And so on.


Jeroen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150618/0e7ef0c8/attachment-0001.htm

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

Message: 3
Date: Thu, 18 Jun 2015 11:35:37 +0200 (CEST)
From: Germ?n Sanchis-Trilles <gsanchis@sciling.com>
Subject: Re: [Moses-support] Major bug found in Moses
To: Tom Hoar <tahoar@precisiontranslationtools.com>
Cc: moses-support@mit.edu
Message-ID: <alpine.DEB.2.10.1506181122230.2518@mgersantr2>
Content-Type: text/plain; charset="iso-8859-15"

I just wanted to chip in a couple of cents from my side.

First, I agree with Tom: my most sincere admiration for the patience you
all have evidenced when answering in this thread. It is certainly not easy
to keep calm when someone is saying that all your work in the last 10
years is wrong.

Second, I think it would be a really good idea to pin this thread
somewhere, perhaps clean it up a bit, and save it for the future: I think
future researchers and NLP students would be able to learn a real lot by
reading through it, it might constitute the most comprehensive guide to
explaining [at least some aspects of] the decoding process I have read so
far.

Finally, regarding James' claims:

> 1) So if I've understood you correctly you are saying we have a system
> that is purposefully designed to perform poorly with a disabled LM and
> this is the proof that the LM is the most fundamental part.

Nope. This misses the point. The system is designed to optimize something
that is unoptimized. It *does not care* about what happens when sticks are
thrown into the system's wheels. It's like a gas engine: it's designed to
do the most out of the gas you poor into it. It *does not care* about what
happens when you poor olive oil into it. The point is not about
purposefully designing something to perform poorly in poor conditions, the
point is about designing something that performs as good as possible with
the conditions we have: because, at the end of the day, what we care about
is having a system that is able to yield good (or fair) translation
quality.


> 2) If you still feel that the LM is the most fundamental component I
> challenge you to disable the TM and perform LM only translations and see
> what kind of BLEU scores you get.

I think Marcin meant that the LM is the strongest feature from all the
individual features available in the system. Disabling the TM is disabling
a bunch of individual features, not just one. And anyway, this misses the
point too: we care about doing the best we can with what we have, not
about what happens when you poor olive oil into a gas engine.

Best,

Germ?n Sanchis-Trilles
Co-founder Sciling S.L.
Tel: +34 658272899
email: gsanchis@sciling.com

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

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


End of Moses-support Digest, Vol 104, Issue 42
**********************************************

Tweet