-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
Hey guys, any update on this? |
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. |
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, |
Thanks for the update @VincentDerk and agreed re the fever/healthy comment 👍 |
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:
The text was updated successfully, but these errors were encountered: