Re: [Moses-support] Weird code in Hypothesis::RecombineCompare()

2015-06-25 Thread Jeroen Vermeulen
On 25/06/15 15:55, Barry Haddow wrote: From memory, I think you are correct. For recombination we only care if the FF states are equal or not equal, the actual order does not matter. The hypotheses are added to an (ordered) set when they get created, where the orderer uses the

[Moses-support] Weird code in Hypothesis::RecombineCompare()

2015-06-25 Thread Jeroen Vermeulen
Looking at replacing WordsBitmap's implementation with std::vectorbool (less code, less memory) I came across this function: « /** check, if two hypothesis can be recombined. this is actually a sorting function that allows us to keep an ordered list of hypotheses. This makes recombination

Re: [Moses-support] Weird code in Hypothesis::RecombineCompare()

2015-06-25 Thread Marcin Junczys-Dowmunt
I'm pretty sure that's the major bug we missed until now ;) W dniu 2015-06-25 10:09, Jeroen Vermeulen napisał(a): Looking at replacing WordsBitmap's implementation with std::vectorbool (less code, less memory) I came across this function: « /** check, if two hypothesis can be

Re: [Moses-support] Weird code in Hypothesis::RecombineCompare()

2015-06-25 Thread Jeroen Vermeulen
On 25/06/15 15:41, Hieu Hoang wrote: i don't think m_ffStates[i] can be null and compare.m_ffStates[i] can ever be NOT null. it should be an assert of UTIL_THROW_IF(...), rather than an if statement That's a little beyond my ken though... I'm nervous enough about touching code here that

Re: [Moses-support] Weird code in Hypothesis::RecombineCompare()

2015-06-25 Thread Hieu Hoang
i don't think m_ffStates[i] can be null and compare.m_ffStates[i] can ever be NOT null. it should be an assert of UTIL_THROW_IF(...), rather than an if statement On 25/06/2015 12:09, Jeroen Vermeulen wrote: Looking at replacing WordsBitmap's implementation with std::vectorbool (less code,