codeaudit / rockit

Automatically exported from code.google.com/p/rockit
0 stars 0 forks source link

Interpretation of output.db #2

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I am trying to interpret the output produced by the MAP estimation of the 
Rockit online service. 

The "output.db" file, does it only list the atoms that are set as True? (and 
all the others implicitly assumed to be false)

Surprisingly, I see that many of the atoms I get are part of the evidence.db. 
Is this intentional? Which atoms get listed there?

Original issue reported on code.google.com by razor4...@gmail.com on 24 Nov 2014 at 8:23

GoogleCodeExporter commented 9 years ago
Yes, the output.db lists those atoms that are True in the MAP state. Every atom 
in the evidence is also part of the output because atoms in the evidence are 
assumed to be true (unless, of course, if you set them to false by negating 
them).

If you think there's something wrong with the output, please attach your model 
and evidence files. 

Original comment by mniepert on 2 Dec 2014 at 2:12

GoogleCodeExporter commented 9 years ago
I think there is actually a problem in Rockit when negations, constants and 
negative weights are combined.

Consider the following evidence

evidence.db
------------
Smokes("A")
Smokes("B")

And the two mln files:

prog1.mln
------------
 1 Friends(x,"A")  

prog2.mln
------------
 -1 !Friends(x,"A")

prog1 returns 

Friends("B", "A")
Friends("A", "A")

however, prog2 returns an empty file, although the MAP state should be the same!
As far as I can tell this seems a bug. 

For single-atom formulas, it is easy to convert from one to the other, but if 
the formula has multiple atoms it is not so easy as it may not be possible to 
get around the conjunction...

Best, 
Roderick

Original comment by razor4...@gmail.com on 5 Dec 2014 at 5:06

GoogleCodeExporter commented 9 years ago
I could replicate the behavior, thanks! I narrowed it down to the cutting place 
inference algorithm. When CPI is deactivated, the output is as expected. We are 
currently working on a fix to this problem. 

Original comment by mniepert on 5 Dec 2014 at 8:06