Post-processing stage

[sthiele]

Hi everyone,

As discussed in our last meeting, I will try to summarize my thoughts on post-processing.

Many of our applications use rules in the encoding that are only for post-processing and output formatting.

It is nice to write this post-processing logic in the same language as the encoding and being able to use the advanced features of gringo instead of writing more complicated imperative code.

Unfortunately, our current implementation has some shortcomings that often require our application to implement more complicated post-processing procedures.

1. For one, there are performance implications Show statements rework #477.

2. If propagators are used in the post-processing, we often want to include the information stored in the propagator. With the current implementation, it is not possible to access this information from the same encoding. To still use the features of the gringo lang sometimes a second grounding step is implemented.

This leads to the problem that if custom post-processing is applied, other components like the testing framework also need to be adjusted to this custom post-processing stage.

This could be avoided if we already provided good post-processing capabilities together with an interface to access the post-processed models.

In the future, we want to avoid duplicating solutions and reinventing the wheel. Therefore, I’d like to start a discussion to develop a design for a solution to these problems that can be reused in the various applications.

Goals

• We want to express our post-processing in gringo language next to the core encoding without a negative performance impact.
• We want to access/provide data from the propagator in/to post-processing stage
• We want to provide an interface to applications to access the post-processed model information.

Questions

• Should the distinction of these post-processing rules be explicit or automatic? I think @MaxOstrowski ngo can detect such rules. On the other hand, we could use the #show directive or an explicit program part for post-processing.

@daveraja @teiesti @susuhahnml

[MaxOstrowski]

I think keeping this parts explicit (like in a show statement) is the way to go. ngo could still then rewrite some rules that it deems to be "post-processing" to show statements.

[sthiele]

I also prefer making it explicit. But momentarily, I think I'd rather have it in an explicit part for post-processing.

...
#program post_processing.
ab(X,Y) :- a(X), not a(Y), Y=X+1.
...

One could amend the constructor for the Control object with a switch to turn post-processing on.
Then one could still run old programs without changing their semantics.
And for both ways (w/o post-processing) the same methods to access models can be used.

Also, this would avoid littering the encoding with #show statements and maybe force a nice separation of core encoding and post-.processing.

[MaxOstrowski]

This actually looks more like a paradigm shift. Your post_processing is ignored by default. And what you want is to evaluate it GIVEN an already computed model.
So this would be more like, evaluate a program post_processing given the following assignment. And this process could be speed up using the assumption that the program post_processing can be evaluated at ground time.