Handy python wrapper around Potassco's Clingo ASP solver.
Clyngor offers multiple interfaces. The followings are all equivalent. (they search for formal concepts)
from clyngor import ASP, solve
answers = ASP("""
rel(a,(c;d)). rel(b,(d;e)).
obj(X):- rel(X,_) ; rel(X,Y): att(Y).
att(Y):- rel(_,Y) ; rel(X,Y): obj(X).
:- not obj(X):obj(X).
:- not att(Y):att(Y).
""")
for answer in answers:
print(answer)
The same, but with the lower level function expecting files:
answers = solve(inline="""
rel(a,(c;d)). rel(b,(d;e)).
obj(X):- rel(X,_) ; rel(X,Y): att(Y).
att(Y):- rel(_,Y) ; rel(X,Y): obj(X).
:- not obj(X):obj(X).
:- not att(Y):att(Y).
""")
More traditional interface, using file containing the ASP source code:
answers = solve('concepts.lp'): # also accepts an iterable of file
More examples are available in the unit tests.
Once you get your answers, clyngor allows you to specify the answer sets format using builtin methods:
for answer in answers.by_predicate.first_arg_only:
print('{' + ','.join(answer['obj']) + '} × {' + ','.join(answer['att']) + '}')
And if you need a pyasp-like interface:
for answer in answers.as_pyasp:
print('{' + ','.join(a.args()[0] for a in answer if a.predicate == 'obj')
+ '} × {' + ','.join(a.args()[0] for a in answer if a.predicate == 'att') + '}')
Currently, there is only one way to see all chaining operator available:
the source code of the Answers object.
(or help(clyngor.Answers)
)
If the used version of clingo is compiled with python, you can put python code into your ASP code as usual. But if you also have the clingo package installed and importable, clyngor can use it for various tasks.
Using the official API leads to the following changes :
You can activate the use of the clingo module by calling once clyngor.activate_clingo_module()
or calling clyngor.solve
with argument use_clingo_module
set to True
.
For users putting some python in their ASP, clyngor may help. The only condition is to have clingo compiled with python support, and having clyngor installed for the python used by clingo.
Clyngor provides converted_types
function,
allowing one to avoid boilerplate code based on type annotation when
calling python from inside ASP code.
Example (see tests for more):
#script(python)
from clyngor.upapi import converted_types
@converted_types
def f(a:str, b:int):
yield a * b
yield len(a) * b
#end.
p(X):- (X)=@f("hello",2).
p(X):- (X)=@f(1,2). % ignored, because types do not match
Without converted_types
, user have to ensure that f
is a function returning a list,
and that arguments are of the expected type.
Note that the incoming clingo version is leading to that flexibility regarding returned values.
Propagators are presented in this paper. They are basically active observers of the solving process, able for instance to modify truth assignment and invalidate models.
As shown in clyngor/test/test_propagator_class.py, a high-level propagator class built on top of the official API is available, useful in many typical use-cases.
As shown in examples/pyconstraint.lp, clyngor also exposes some helpers for users wanting to create propagators that implement an ASP constraint, but written in Python:
#script(python)
from clyngor import Constraint, Variable as V, Main
# Build the constraint on atom b
def formula(inputs) -> bool:
return inputs['b', (2,)]
constraint = Constraint(formula, {('b', (V,))})
# regular main function that register given propagator.
main = Main(propagators=constraint)
#end.
% ASP part, computing 3 models, b(1), b(2) and b(3).
1{b(1..3)}1.
An idea coming from the JSON decoders, allowing user to specify how to decode/encode custom objects in JSON. With clyngor, you can do something alike for ASP (though very basic and only from ASP to Python):
import clyngor, itertools
ASP_LIST_CONCEPTS = """ % one model contains all concepts
concept(0).
extent(0,(a;b)). intent(0,(c;d)).
concept(1).
extent(1,(b;e)). intent(1,(f;g)).
concept(2).
extent(2,b). intent(2,(c;d;f;g)).
"""
class Concept:
"Decoder of concepts in ASP output"
def __init__(self, concept:1, extent:all, intent:all):
self.id = int(concept[0])
self.extent = frozenset(arg for nb, arg in extent if nb == self.id)
self.intent = frozenset(arg for nb, arg in intent if nb == self.id)
def __str__(self):
return f"<{self.id}: {{{','.join(sorted(self.extent))}}} × {{{','.join(sorted(self.intent))}}}>"
objects = clyngor.decode(inline=ASP_LIST_CONCEPTS, decoders=[Concept])
print('\t'.join(map(str, objects)))
This code will print something like:
<2: {b} × {c,d,f,g}> <0: {a,b} × {c,d}> <1: {b,e} × {f,g}>
Note the use of annotations to declare that each concept
must be associated to one instance,
and that all extent
and intent
must be sent to constructor for each object.
See tests for complete API example.
Remaining features for a good decoder support:
(3, 5)
(to ask for between 3 and 5 atoms to be associated with the instance), or any
(exact meaning has to be found)Clyngor is basically the total rewriting of pyasp, which is now abandoned.
For an ORM approach, give a try to clorm.
pip install clyngor
You must have clingo
in your path. Depending on your OS, it might be done with a system installation,
or through downloading and (compilation and) manual installation.
You may also want to install the python clingo module, which is an optional dependancy.
By default, clyngor uses a very simple parser (yeah, str.split
) in order to achieve time efficiency in most time.
However, when asked to compute a particular output format (like parse_args
) or an explicitely careful parsing,
clyngor will use a much more robust parser (made with an arpeggio grammar).
See the utils
module and its tests,
which provides high level routines to save and load answer sets.
import clyngor
clyngor.CLINGO_BIN_PATH = 'path/to/clingo'
Note that it will be the very first parameter to subprocess.Popen
.
The solve
function also support the clingo_bin_path
parameter.
The third solution is to use the decorator with_clingo_bin
, which modify the global variable
during the execution of a specific function:
import clyngor
@clyngor.with_clingo_bin('clingo454')
def sequence():
...
clyngor.solve(...) # will use clingo454, not clingo, unless clingo_bin_path is given
...
clyngor.solve
parametersThe solve
functions allow to pass explicitely some parameters to clingo
(including number of models to yield, time-limit, and constants).
Using the options
parameter is just fine, but with the explicit parameters some verifications
are made against data (mostly about type).
Therefore, the two followings are equivalent ; but the first is more readable and will crash earlier with a better error message if n
is not valid:
solve('file.lp', nb_model=n)
solve('file.lp', options='-n ' + str(n))
No.
Yes.
No, it's pronounced clyngor.
Clyngor was designed to not require the official module, because it required a manual compilation and installation of clingo. However, because of the obvious interest in features and performances, the official module can be used by clyngor if it is available.
.int_not_parsed
.#show 3.
and #show "hello !".
are now handled.with_answer_number
, giving model, optimization, optimality and answer numbera((a("g(2,3)",(2)),))
is now correctly handled and testedmodels.command
output when clingo module is usedopt_models_from_clyngor_answers
by using yield and answer number, but is now a generator and loses (the useless) repeated_optimal
optionTermSet.add
to add atoms to the TermSetTermSet.union
to generate the union of multiple TermSet instancesreturn_raw_output
for clyngor.solve, allowing to get stdout/stderr without treatmentsopt_models_from_clyngor_answers
is now embedded in clyngor API.by_arity
, equivalent to .by_predicate
but with predicate and aritywith_clingo_bin
, changing clingo binary path for encapsulated function.with_optimality
, giving optimization and optimality along with the modelclyngor.decoder
and doc.discard_quotes
option (thanks to ArnaudBelcour).atom_as_string
and .first_arg_only
collisionIf you have a project that makes use of pyasp, but need clingo instead of gringo+clasp, one way to go is to use clyngor instead.
Here was my old code:
from pyasp import asp
def solving(comp, graph):
programs = [comp, graph]
clasp_options = ['--opt-mode=optN', '--parallel-mode=4', '--project']
solver = asp.Gringo4Clasp(clasp_options=clasp_options)
print("solver run as: `clingo {} {}`".format(' '.join(programs), clasp_options))
at_least_one_solution = False
for answerset in solver.run(programs, collapseAtoms=False):
yield answerset
def find_direct_inclusions(model) -> dict:
programs = [ASP_SRC_INCLUSION]
solver = asp.Gringo4Clasp()
add_atoms = ''.join(str(atom) + '.' for atom in model)
answers = tuple(solver.run(programs, collapseAtoms=False,
additionalProgramText=add_atoms))
return answers
And here is the version using clyngor, that pass the exact same unit tests:
import clyngor
def solving(comp, graph):
programs = [comp, graph]
clasp_options = '--opt-mode=optN', '--parallel-mode=4', '--project'
answers = clyngor.solve(programs, options=clasp_options)
print("solver run as: `{}`".format(answers.command))
for answerset in answers.as_pyasp.parse_args.int_not_parsed:
yield answerset
def find_direct_inclusions(model) -> dict:
programs = [ASP_SRC_INCLUSION]
add_atoms = ''.join(str(atom) + '.' for atom in model)
answers = tuple(clyngor.solve(programs, inline=add_atoms).as_pyasp.parse_args)
return answers
To Arnaud Belcour for his works and frequent feedbacks.
To Domoritz for his questions and feedbacks.