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: Illegal division by zero in mteval-v13a.pl (Kenneth Heafield)
2. Re: Illegal division by zero in mteval-v13a.pl (Dingyuan Wang)
3. Re: g++: error: unrecognized command line option
'-no-cpp-precomp' (Jorg Tiedemann)
4. Re: Decoding Speed perfomance - suggestion and question
(Philipp Koehn)
----------------------------------------------------------------------
Message: 1
Date: Mon, 31 Aug 2015 14:39:38 +0100
From: Kenneth Heafield <moses@kheafield.com>
Subject: Re: [Moses-support] Illegal division by zero in
mteval-v13a.pl
To: moses-support@mit.edu
Message-ID: <55E4591A.6000802@kheafield.com>
Content-Type: text/plain; charset=windows-1252
You have a zero-length line. BLEU isn't well defined for this case.
Though it would be nicer if NIST's script provided a better error
message/had an option to skip empty lines.
On 08/31/2015 02:33 PM, Dingyuan Wang wrote:
> Dear all,
>
> When using EMS, step EVALUATION:test:nist-bleu(-c) crashed with "Illegal
> division by zero at mteval-v13a.pl line 890".
>
> I saw this error first time, and training the other direction with the
> same config is fine. Previous experiments didn't cause this error.
>
> The script is the latest version on GitHub.
>
> Attached is the files that causes the problem. The command line is:
> perl mteval-v13a.pl -s t.zhc-zh.zhc.sgm -r t.zhc-zh.zh.sgm -t
> test.detokenized.sgm.2
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
------------------------------
Message: 2
Date: Mon, 31 Aug 2015 21:46:56 +0800
From: Dingyuan Wang <abcdoyle888@gmail.com>
Subject: Re: [Moses-support] Illegal division by zero in
mteval-v13a.pl
To: Kenneth Heafield <moses@kheafield.com>, moses-support@mit.edu
Message-ID: <55E45AD0.6000604@gmail.com>
Content-Type: text/plain; charset=windows-1252
Thanks. It's my mistake when preprocessing the test set.
> You have a zero-length line. BLEU isn't well defined for this case.
> Though it would be nicer if NIST's script provided a better error
> message/had an option to skip empty lines.
>
> On 08/31/2015 02:33 PM, Dingyuan Wang wrote:
>> Dear all,
>>
>> When using EMS, step EVALUATION:test:nist-bleu(-c) crashed with "Illegal
>> division by zero at mteval-v13a.pl line 890".
>>
>> I saw this error first time, and training the other direction with the
>> same config is fine. Previous experiments didn't cause this error.
>>
>> The script is the latest version on GitHub.
>>
>> Attached is the files that causes the problem. The command line is:
>> perl mteval-v13a.pl -s t.zhc-zh.zhc.sgm -r t.zhc-zh.zh.sgm -t
>> test.detokenized.sgm.2
>>
>>
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 3
Date: Mon, 31 Aug 2015 17:14:10 +0300
From: Jorg Tiedemann <tiedeman@gmail.com>
Subject: Re: [Moses-support] g++: error: unrecognized command line
option '-no-cpp-precomp'
To: Hieu Hoang <hieuhoang@gmail.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID: <FD47806E-CE89-419F-9FD8-3C7451BCB0F0@gmail.com>
Content-Type: text/plain; charset="utf-8"
Well, I have /opt/local/ search paths in various environment variables to get macports to work.
I deleted all this paths and tried again but I still get the same problem.
I am confused. And why is gcc not working anymore when installed via macports? I also installed boost with macports. Is that a problem as well?
I have also some problems with kenlm but part of it compiles and links fine. build_binary and query seems to compile fine but lmplz does not link because of some undefined symbols:
Undefined symbols for architecture x86_64:
"boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) const", referenced from:
?.
I also had to link /opt/local/lib to /opt/local/lib64 (which didn?t exist in my setup).
I am afraid that I started to make quite a mess on my system but what did I do wrong?
Is macports not working properly anymore?
As I said, I have gcc 5.2.0 and boost 1.59.0 via macports on my system. Is that bad?
Thanks for helping!
J?rg
> On 31 Aug 2015, at 16:19, Hieu Hoang <hieuhoang@gmail.com> wrote:
>
> the errors for clang looks like it's coming from the stl library. Have you fiddled with the PATH variable or otherwise tried to make gcc on OSX work? You shouldn't do that, it will just mess up the compilation environment on your machine
>
> On 31/08/2015 10:28, Jorg Tiedemann wrote:
>>
>> Unfortunately, this didn?t work for me either. I attach both logiles - one for clang and one for gcc (which I installed via macports)
>> What can I do? Thanks!
>>
>> J?rg
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 30 Aug 2015, at 11:33, Hieu Hoang < <mailto:hieuhoang@gmail.com>hieuhoang@gmail.com <mailto:hieuhoang@gmail.com>> wrote:
>>>
>>> Add
>>> toolset=clang
>>> to the bjam compile command. Osx no longer has gcc
>>>
>>> Hieu Hoang
>>> Sent while bumping into things
>>>
>>> On 29 Aug 2015 11:56 pm, "Jorg Tiedemann" <tiedeman@gmail.com <mailto:tiedeman@gmail.com>> wrote:
>>> Hi,
>>>
>>> I tried to make a fresh install of Moses on my new Mac and I get the following error
>>> g++: error: unrecognized command line option '-no-cpp-precomp'
>>>
>>> What?s wrong? I have gcc5 and boost 1.59 on my machine via macports ...
>>>
>>> Thanks for your help!
>>> J?rg
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu <mailto:Moses-support@mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/moses-support <http://mailman.mit.edu/mailman/listinfo/moses-support>
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu <mailto:Moses-support@mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/moses-support <http://mailman.mit.edu/mailman/listinfo/moses-support>
>>
>
> --
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> http://www.hoang.co.uk/hieu <http://www.hoang.co.uk/hieu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20150831/a657e2e3/attachment-0001.html
------------------------------
Message: 4
Date: Mon, 31 Aug 2015 10:14:24 -0400
From: Philipp Koehn <phi@jhu.edu>
Subject: Re: [Moses-support] Decoding Speed perfomance - suggestion
and question
To: Vincent Nguyen <vnguyen@neuf.fr>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAAFADDCXhR2aRMcdJ=vPmaxAL8kQERNTuYRo5z42jza-gG=gSQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I would suspect that with beam sizes <500 the bulk of the time is
spent on translation option collection, not decoding. You could speed
that up with tighter threshold pruning of the phrase table.
See the script scripts/training/threshold-filter.perl or the setting
score-settings = "--MinScore 2:0.0001"
in EMS.
-phi
On Mon, Aug 31, 2015 at 3:03 AM, Vincent Nguyen <vnguyen@neuf.fr> wrote:
> Hi,
>
> Here are some results with several values with cube pruning pop limit :
>
> (pop limit / decoding time for 3000 sentences / BLEU score)
>
> 5000 - 15m45 - 29.59
> 1000 - 4m27 - 29.59
> 500 - 3m35 - 29.59
> 200 - 3m15 - 29.51
> 100 - 3m00 - 29.40
>
> Therefore I took 400 - 3m19 - 29.58
>
> If I am not mistaken the default value for Moses is 1000 [read in the
> doc] but in the EMS
> it is 5000 right now .... which makes the experience so long .....
> I suggest to change the EMS default value.
>
> Is there a way to also use a cube pruning limit in the decoder at Tuning
> time ?
>
> Now with this optimized setting I get a ration of 15 segments per second
> in average.
> What is the reason for online tools like Google / Bing to be much much
> faster.
> it's not a machine issue, is it ?
>
>
> Cheers
> Vincent
>
> _______________________________________________
> 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/20150831/5cb7ce7f/attachment.html
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 106, Issue 56
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 106, Issue 56"
Post a Comment