error in updateing beliefs

[gasparz]

Hi,

I am automatically building a BN and when the node count is larger than 678 the UpdateBeliefs() function gives

-6.2774385622041925e+066

for the probability of a state for more than one node.

Did anyone else experience this problem?

Thanks,
Gasparz

[shooltz[BayesFusion]]

I am automatically building a BN and when the node count is larger than 678 the UpdateBeliefs() function gives
-6.2774385622041925e+066

Hard to tell without seeing actual network you're building. The problem may be related to loss of precision - do you have one parent with large (> 500) number of children?

[gasparz]

In my case the network looks like:

p1-> children1 (evidence is set)
|
p2 -> children2 (evidence is set)
|
p3 -> children3 (evidence is set)
....
|
pn-> children3 (evidence is set)

where if n=339 the results are ok (probability values between 0 and 1)
if n= 340 the results for all px (x in 1 to 340) is -6.2774385622041925e+066 )

This network has a simple tree structure, one parent has 2 children (the next parent and 1 real children (leaf)) and I am using the default update belief algorithm. You can imagine this structure as a DBN but as the samples are not taken at uniform points of time the probabilities between the time slices are different (following a linear function in my case).

The probabilities in the network are well defined because I saved the network and loaded it in genie and run it giving me good results. As I cannot save the network with the evidence (I seen the other post and will try it with the cases) I couldn't try it in Genie. Setting 340 nodes with evidence manually in Genie is not an option (way too much work and I can't even save it)

Thanks,
Gasparz

[gasparz]

I saved the evidence in a case, load the BN in Genie added the evidence from the case and updated the beliefs.

Genie handled it quite well, the probabilities shown were:

poor <0.001
Good = 1

there was no -6.2774385622041925e+066 anywhere. I can understand that with the limited precision (double has a huge precision but is not infinite) in some cases a probability of 0 or 1 can appear.

In these cases the smile api should return 0 or 1 and not -6.2774385622041925e+066, the reason why I consider this a bug.

I can provide the saved xsdl file if needed.

Thanks,
Gasparz

[shooltz[BayesFusion]]

In these cases the smile api should return 0 or 1 and not -6.2774385622041925e+066, the reason why I consider this a bug.

That's definitely a bug -6.2e+066 is a number with very large absolute value. Please post the xdsl file.

[gasparz]

here is the file

[shooltz[BayesFusion]]

It's the problem with floating point accuracy after all. I ran DSL_network::UpdateBeliefs on your model with the 'case 1' applied, using Microsoft's compiler included in VStudio 2008 (VC++ 9.0). Using release build I got the numbers corresponding to the GeNIe output. On the other hand, the debug build can't calculate the beliefs correctly. This is caused by underflows during the final stages of clustering. You can verify that by adding the following lines just before the call to UpdateBeliefs in your code:

Code: Select all

_clearfp();
_controlfp(_EM_INEXACT, _MCW_EM);

The C++ exception will be thrown from within SMILE when underflow happens.

The release build works correctly (no fp exceptions), most likely due to optimizations like changing x /= y inside some internal SMILE loop to x *= z, where z = 1/y calculated before entering the body of the loop.

Publicly available GeNIe build is compiled with full optimizations, so it was able to complete the UpdateBeliefs call without encountering underflows.

Note that -6.2774385622041925e+066 is a value resulting from interpreting the 8-byte pattern of 0xCD as a double. 0xCD is one of the values used by VisualC++ in debug mode to fill uninitialized heap space. Also, you should call DSL_nodeValue::IsValueValid before reading the entries in the belief matrix. In your network, IsValueValid returns false for all non-evidence nodes except trunk_3_1184910096_493867.