potassco / clasp

⚙️ A conflict-driven nogood learning answer set solver

Home Page:https://potassco.org/clasp/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

configuration files returns different results as using the same options in the command line

kstrauch94 opened this issue · comments

Using configuration files to run clingo gives different results(solving time, choices, conflicts, etc) to just running the same options on the command line. I tried this initially with clingo-dl but it is also different when running the clingo examples from the repository.

If I have a configuration file named config.c with the contents:
[tweety]: --heuristic=Domain

Running this command on a 15puzzle instance :
clingo examples/clingo/15puzzle/encoding.lp examples/clingo/15puzzle/instance1.lp --stats --quiet=2 --configuration=config.c

gives different results to this command:
clingo examples/clingo/15puzzle/encoding.lp examples/clingo/15puzzle/instance1.lp --stats --quiet=2 --configuration=tweety --heuristic=Domain

Is this some side effect of using the configuration files or is it a bug?

To be honest, I do not understand how to use the --configuration=<file> option just by reading the --help=3 output and the explanations given with --print-portfolio. Maybe @BenKaufmann can shed some light on this?

@kstrauch94
You are applying two completely different configs, which only happen to have the same name. --config=tweety applies the options of the tweety configuration as shown by --help=3. Your config file defines its own tweety config with exactly one option (--heuristic=Domain).

If you want to have a config file config based on one of the default configs, you have to use the syntax described in the output of --print-portfolio:

A configuration file contains a (possibly empty) list of configurations.
Each of which must have the following format: <name>[(<config>)]: <cmd>
where <name> is a string that must not contain ':',
<config> is one of clasp's default configs (and optional) and <cmd>is a command-line string of clasp options in long-format

Hence, to get the base config "tweety" , you have to add (tweety) after your config name:
[tweety](tweety): --heuristic=Domain
or less confusing:
myconfig(tweety): --heuristic=Domain

The second thing to rember is that global options (like e.g. preprocessor options) are ignored in config files, unless explicitly given in the first config. Hence, to get the exact same tweety config, you'd have to write:
myconfig(tweety): --heuristic=Domain --eq=3 --trans-ext=dynamic.

@rkaminsk
Do you have a suggestion for making the output of --print-portfolio more obvious?

Do you have a suggestion for making the output of --print-portfolio more obvious?

At first I was not getting what the name means and was wondering why there are brackets. Now I see that the names are just arbitrary descriptions without any meaning and the brackets are optional. Maybe we can give the example above in the comments when printing the default portfolio? I also feel we should mention the treatment of global options in --print-portfolio because it is something others might stumble over.

NOTE: Global options have to be explicitly given in the first configuration
after the colon. Global options from a default configuration will not be
applied.

EXAMPLE: We can base off the configuration of the first solver on clasp's
inbuilt tweety configuration by writing

[solver.0](tweety): --eq=3 --trans-ext=dynamic

in the first line. Here we explicitily have to add global options after the
colon. Note that the name `solver.0` only serves as a description; any name
can be chosen. Furthermore, note that the brackets are just part of the name
and we can equivalently write:

solver.0(tweety): --eq=3 --trans-ext=dynamic

Nice. Thanks!