Menu

#35 fixed-lag smoothing with lag 0 throws errors

v1.0_(example)
open
nobody
None
5
2007-04-13
2007-04-13
Anonymous
No

As far as I can tell, when you create a 0-lag FixLagSmoothing 1.5-slice JTree Inference Engine there are a couple of places where this boundary condition is not properly tested, leading to errors.

The nature of the problem is that the CRing template doesn't seem to have a manipulable iterator when its size is zero. Also calling front on an empty intVector produces an error, and this case is not tested for either.

The former causes a problem when lag=0 in C1_5SliceJtreeInfEngine::EnterEvidence in the following chunk of code:
if( m_CRingpEv.size() < size )
{
m_CRingpEv.push_back( pNewEvidence );
evidIter++;
}
It appears that because evidIter is initialized higher up, before push_back is called and thus when m_CRingpEv is empty, evidIter is bogus and the increment operator++ throws an error. I was able to work around this by adding an additional conditional clause:
if( m_CRingpEv.size() == 0 )
{
m_CRingpEv.push_back( pNewEvidence );
evidIter = m_CRingpEv.begin();
evidIter++;
}
else if( m_CRingpEv.size() < size )
...

The intVector issue causes a problem (like I said, when using lag=0) in CJunctionTree::SetNodeTypes at the call to pnlDetermineDistributionType. &obsNodesInClq.front()can't be evaluated; fortunately since pnlDetermineDistributionType doesn't use this argument when the obsNodesInClq.size() argument is zero, I replaced arg 3 with "(obsNodesInClq.size() == 0) ? NULL : &obsNodesInClq.front()" and this seems to fix the problem.

Between these two edits, I was able to use FixLagSmoothing with lag=0. I think these changes should be added to the source.

h

Discussion


Log in to post a comment.