Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

subquery/2 and /3 always use the ProbabilitySemiring #40

Open
VincentDerk opened this issue Jan 2, 2020 · 5 comments
Open

subquery/2 and /3 always use the ProbabilitySemiring #40

VincentDerk opened this issue Jan 2, 2020 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@VincentDerk
Copy link
Collaborator

In subquery/2 (and /3), the semiring is not passed on to the sub evaluation. This means custom semirings or the HALSemiring (continuous vars) do not yet work properly.

Example for dcproblog_develop branch:

b~beta(0.5,1).
c :- b > 1.
event :- subquery(c, Prob), writeln(Prob).
query(event).
@shuvrobiswas
Copy link

Hey guys, any update on this?

@pedrozudo
Copy link
Contributor

Hi,

Yeah sorry, last couple of weeks have been super hectic. We briefly looked at it and could not come up with a quick and general fix. I'll be working on improving support continuous random variables over the next weeks. I hope I can get around fixing this issue, too.

@shuvrobiswas
Copy link

Hey guys, any timeline on this issue and/or any way I can help?

Created a simple covid19 example (with just plain problog, no continuous variables):

image

@VincentDerk
Copy link
Collaborator Author

Unfortunately I have been swamped with other things, hard to tell when I can look into this again. I don't know whether @pedrozudo found time?

From what I remember, the problem was the current design structure where the engine had no knowledge of the semiring. We could not just pass on a semiring to the engine because the semiring might be based on the results from the engine (for example in the implementation for continuous variables).

I was opting for a user defined function to create a semiring given an engine but I believe there was another reason that made me change my mind. Something to do with how the implementation in the continuous case is done with a Solver and was not necessarily following the procedure in subquery.

Regarding the comment in your example, 0::fever(X) :- healthy(X). adds a reason for fever(X) to become true (even though it will not change the results as you attached a probability of 0). \+ fever(X) :- healthy(X). says that it is impossible to have a fever when you are healthy. It overrides any other rule that could have otherwised caused fever while being healthy.

@shuvrobiswas
Copy link

Thanks for the update @VincentDerk and agreed re the fever/healthy comment 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants