Hi Lakshya,
Thanks for clarification. Could you please share the code snipped, how you
are passing "nbest" as integer.
On Thu, Apr 17, 2014 at 9:26 AM, Lakshya wrote:
>
> The error is because of "nbest" is not a boolean , but it is an integer
> type. So pass integer parameter.
>
>
> Regards
The error is because of "nbest" is not a boolean , but it is an integer
type. So pass integer parameter.
Regards
Lakshya
-- Forwarded message --
From: Barry Haddow
Date: Thu, Apr 17, 2014 at 12:43 AM
Subject: Re: [Moses-support] Moses server with -n-best-list option
To: Rajnath
Hi, Raymond.
Interesting. Is your parallelization also tolerant to random job failures? How
does it decide when to stop waiting? Cannot it degrade to optimizing only on
eg. one of the splits, all others failing?
An option to commit your code in a more visible way is to put it in the main
branc
HI Raj
Not sure, what does the server log say? Try logging to a file, rather
than /dev/null.
cheers - Barry
On 16/04/14 18:25, Rajnath Patel wrote:
Hi Barry,
Thanks for quick reply. As you suggested now I am requesting with
"nbest=true" as - "mosesParams.put("nbest", "true");". Code is
at
Hi Barry,
Thanks for quick reply. As you suggested now I am requesting with
"nbest=true" as - "mosesParams.put("nbest", "true");". Code is attached
here with. Now its throwing Exception-
--
Exception in thread "main" org.apache.xmlrpc.XmlRpcException: Unexpected
error executing code for parti
Raymond,
I would be very interested to see what you have. I agree that there are
definitely environments where short jobs are required or preferred.
Thanks,
Lane
On Wed, Apr 16, 2014 at 11:21 AM, Raymond W. M. Ng wrote:
> Dear Ondrej,
>
> I have checked with Hieu when I met him in February, se
Raymond,
I would be very interested to see what you have. I agree that there are
definitely environments where should jobs are required or preferred.
Thanks,
Lane
On Wed, Apr 16, 2014 at 11:21 AM, Raymond W. M. Ng wrote:
> Dear Ondrej,
>
> I have checked with Hieu when I met him in February, s
hi raymond
you're welcome to create a branch on the Moses github repository and add
your code there. It's unlikely anyone will look at it or use it, but at
least it won't get lost.
Maybe in future, you or someone else might want to merge it with the master
branch where it will get much more expos
Hi Raj
You need to specify nbest=true in the request you send to moses server.
There was a thread last week on this, and I think
nbest lists are working,
cheers - Barry
On 16/04/14 15:33, Rajnath Patel wrote:
> Hi,
>
> We are using mosesserver for our translation system. We are using java API
Dear Ondrej,
I have checked with Hieu when I met him in February, seems that the SGE
submission in MERT is using the -sync mode, which makes submission
difficult (user still in submission states until the all jobs end). In
short, the modification runs in a "no-sync" mode.
In terms of efficiency,
Hi,
We are using mosesserver for our translation system. We are using java API
given with the decoder, and its working fine. We want multiple
translations for same text. As in one moses support conversation It was
responded in Sept 2012, that mosesserver do not support -n-best-list
option. Is this
Dear Raymond,
The existing scripts always allowed running MERT in parallel jobs on SGE, one
just had to use generic/moses-parallel as the "moses executable".
Is there some other functionality that your modifications now bring?
Btw, in my experience, parallelization into SGE jobs can be even les
Hi Moses support,
Not sure I am making this enquiry in the right mailing list
I have some modified scripts for parallel MERT tuning which can run on SGE.
Now I would like to share this. It is based on an old version of moses
(around April 2012), what is the best way for sharing?
Best
raymond
Thank you Barry for reply.
So would it be okay if I compare my own developed system with GT?
As my system is also phrase based system.
Kind Regards,
Mr. Asad Abdul Malik
On Wednesday, April 16, 2014 1:42 PM, Barry Haddow
wrote:
Hi Asad
The simple answer is that this is a commercial secr
Hi all,
I guess that might be their preordering implementation, at least the start
of it:
http://www.aclweb.org/anthology/C10-1043.pdf
Best,
Benjamin
-Ursprüngliche Nachricht-
Von: moses-support-boun...@mit.edu [mailto:moses-support-boun...@mit.edu] Im
Auftrag von Barry Haddow
Gesende
Hi Asad
The simple answer is that this is a commercial secret so no-one outside
google really knows. However if you read the papers written by googlers,
and observe the interface carefully, then you can gain a certain amount
of insight. In particular, it's likely that Google translate is
phra
Hi Roee
The -threads switch is intended for command-line Moses, not for Moses
server, but I didn't realise that it had this negative effect on the
Moses server. Moses server uses the threading model provided by xmlrpc-c
which, afaik, creates a new thread for each new tcp/ip connection. The
-th
Hi,
To help diagnose this issue (translations running slowly when parallel), we
tried running Moses server without the -threads switch, on our 8-core server.
This resulted in a significant performance improvement!
It seems that, counter-intuitively, using the -threads switch (with the va
18 matches
Mail list logo
