Many distributions randomize shared library addresses each time you run
an executable in order to make buffer overflow attacks harder.  There's
plenty of things that will make addresses returned by malloc/mmap vary
without threading.

Kenneth

On 03/24/11 10:15, Lane Schwartz wrote:
> On Thu, Mar 24, 2011 at 10:07 AM, Barry Haddow <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     Hi Lane
> 
>     Ideally, moses should return the same output for the same input
>     data. However,
>     as Christian already noted, there are points in the code where pointer
>     comparison is used to determine the order in which the search graph is
>     explored, and this could potentially change the nbest lists.
> 
>     As far as I recall, the pointer comparison happens because we want
>     to use
>     feature state for ordering hypotheses, and for some of the language
>     model
>     features (eg SRI) the state is just a pointer to some implementation
>     specific
>     data. It looks to me as though kenlm implements a proper FFState
>     object, as
>     opposed to using PointerState, so you could try changing language
>     model to
>     see if you get deterministic behaviour.
> 
>     Of course, the problem you're observing could be caused by some
>     other source
>     of non-determinism. You should be able to observe the search graphs
>     diverging
>     by running with -v 3.
> 
>  
> Barry & Christian,
>  
> Thanks for the replies. FWIW, I am not using multiple threads, so that
> shouldn't be an issue.
> I'll give KenLM a try to see if that makes a difference. I'd been
> meaning to try that out anyway.
>  
> The pointer comparison issue seems like a likely culpruit for the case
> where multiple hypotheses are tied and have different order in the
> n-best lists. However, do you think that is a plausible explanation for
> the case where there are translations that appear only in run A, and
> different translations that only appear in run B (and the scores in
> these cases are not tied)?
>  
> Cheers,
> Lane
>  
> 
> 
> 
> _______________________________________________
> Moses-support mailing list
> [email protected]
> http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to