kamel-usp/dpasp

Differentiable probabilistic answer set programming

dpasp's Issues

Learning From Fully Observed Data

Implement efficient techniques for fully observed data (including at least observations of all probabilistic facts). Consider the case of probabilistic logic programs (solved in closed form) and neuro-probabilistic logic programs (still requiring gradient learning). Test with the Sudoku example (learn program that encodes Sudoku rules from images of handwritten sudoku solutions).

Repository of Neural Networks

Create a repository of pre-trained neural networks for common tasks such as object detection, object classification, entity extraction etc. Those networks should be easily accessible from a dpasp program by providing a URL identifier or similar. Maybe use something similar as huggingface or huggingface library itself.

Dependency graph

Build dependency graph to help with grounding of probabilistic facts and accelerate inference

Maximum a Posteriori Inference

Implement algorithms for maximum a posteriori inference, that is, finding the probable interpretation of a selected set of facts. Implement at least a brute-force algorithm and an algorithm that calls clingo or plingo for optimization/sampling. Can start with simple cases (acyclic/stratified programs) then move to programs with cycles and max-ent semantics.

MCMC Inference and Learning

Implement MCMC inference a la PASTA for probabilistic logic programs, then extend it to approximate learning of neural logic programs.

Packaging

Create packages for common distributions (debian/ubuntu, homebrew, what else?) and containerization (docker)

Are Aggregates Fully Supported?

Hi. I'm writing a simple program but the following line:

fb(FB):- #count{ X : f(X), b(X)} = FB.

raises a syntax error (at FB after =).
However, by looking (very quickly) at the grammar in the source code, aggregates seems to be supported, but in limited form.
So, is there a way to represent the previously reported line within this tool?

Thanks.

#Include directives

Allow for a #include "filename.py" or #include "filename.plp" directive that is equivalent to the Python snippet #python #end, but can be used to split a dpasp program into several files. The type of snipper can be deduced from the file extension. That should also help to make things more efficient, as e.g., we might pre-compile python files or pre-ground plp files.