Refactor Interpretation / Model Objects

[gfrances]

I'd like to refactor a bit our design for FOL models. The current Model class is a great starting point, but we should have a (perhaps different) "Planning model" object which takes into account information of which predicate and function symbols are static to minimize the memory footprint and, essentially, is able to do the same key operation than the current models, which is to compute the denotation of any formula or term. The distinction between static / dynamic symbols does unfortunately not belong to FOL per se, which is why I am reluctant to modify the current Model class. We should stick to the principle that "pure FOL" concepts are implemented as cleanly as possible, and planning concepts are implemented separately, possibly as wrappers of the FOL concepts.

The driving motive of this change is not just keeping the memory footprint low by identifying static info, but also achieving a full integration with the DLModels that I have in the lite branch. These are Description Logic models, their key operation is to return the denotation of any DL concept or role. But concepts and roles are just a subclass of FOL, so DLModel should essentially be a thin wrapper over a standard FOLModel (or maybe we don't even need a wrapper). The reason why I implemented that independently was that I needed the static distinction.

We have to keep in mind that a state is a model. I would like to have a couple of creators / adaptors / whatever design pattern we want that take e.g. a pyperplan state and converts it into a Tarski Planning Model. These will be very simple classes, nothing too complicated here.

Finally, the current models are based on Python strings, but eventually we'll want to move to assigning numeric IDs to predicate / function / constant symbols, and keeping everything a bit more performant. I wouldn't do this yet though, better first to get the design of the rest of things right.

[gfrances]

The new Model classes should also take into account axioms and provide a consolidated "view" of an extended state with the value of all primary + secondary state variables. For this, we'd just need to implement some simple axiom evaluation strategy (e.g. the FD algorithm), with the usual assumption that axioms are stratified, etc.

[miquelramirez]

I think that leaving the Model class as it is, is a good thing.

I have a number of project mapping Model into "states" and the pattern that I have observed is the following:

• You usually want to make distinction between symbols whose denotation changes and those which do not.
• The transformations on Model essentially "flatten" the data structure into some sort of vector or tuple of constant symbols.
• An index is kept mapping the symbols to integers for (greater) efficiency.

I am not 100% sure that Python is the best language to implement the kind of data structures you suggest @gfrances. I get good performance in C++ - that is, by crossing over the language mapping symbols (strings or hashes) into (simpler) integers.