Decoupling FS from BFWS: Roadmap

[gfrances]

We need to completely decouple de BFWS engine from the rest of elements in the FS planner.
This needs to be done along the lines outlined in the IJCAI'17 submission: the BFWS component
only interface is a simulation-based one, in which only black-box implementations
of the set of actions A, the set of actions A(s) applicable to a given state,
and some information about the structure of the state (i.e. number and type of variables)
and of the goals (i.e. a decomposition of the set of goals G into possibly-overlapping
sets of subgoals G_i) is needed.

We need a clean, well-documented, and ideally 0-overhead interface.
As a tentative roadmap, the following current components of FS should fall within "FS user space".

• All of the Python front-end
• The FSRIPS language component
• The "applicable-action" iterators
• The hybrid state (?)
• All of the Gecode-based components. The BFWS component needs to be completely independent of Gecode.

And the following current components of FS should fall within the "BFWS component / library":

• The novelty evaluators
• The novelty-feature interfaces
• The IW(k)
• The width-based GBFS search engines.

Of course this last component will have a distinct namespace.
Not sure if it makes sense to wholle integrate it inside of LAPKT or it'd be better of
as a distinct library (or perhaps sub-library) on top of LAPKT.
Special care should be taken to ensure that the components are well-tested, the
physical design is as good as possible to ensure fast compilation times.

[miquelramirez]

All those contributions would be very welcome to LAPKT @gfrances. @nirlipo and me have discussed where to take it, after what we have learnt and we are in agreement that having there basic components, as the ones you mention, is the way to go.

[nirlipo]

yep, I agree with the division. Would be great to reorganize LAPKT / FS / Width-based Algs. Perhaps maintaining our previous divisions of 1 - Parsers / grounders 2 - Problem representations (here we can have, STRIPS, Hybrid planning, FSTRIPS, Black-Box Simulators) 3 - Algorithms Cheers, Nir

…

On Tue, Feb 21, 2017 at 12:16 AM, Miquel Ramírez ***@***.***> wrote: All those contributions would be very welcome to LAPKT @gfrances <https://github.com/gfrances>, @nirlipo <https://github.com/nirlipo> and me have discussed where to take it, and we are in agreement that having there basic components, as the ones you mention, is the way to go. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0mVs-J8sGrgKxxfbUVRuN6l3dTTmLnks5reZI8gaJpZM4MGJib> .

[gfrances]

I'm just looking into this now... I was thinking on a module-based division (e.g. à la Boost, but much simpler of course !!), where we can have the development of different components in different repos, and then a simple 'install' script copying headers and library files into a common installation directory.

So for instance I would decouple some things which are in FS right not into a separate project / repo lapkt-novelty. This module would depend only on the base lapkt, and could be compiled standalone.
There'd be a install script which simply copies the whole tree substructure into a general installation directory:

~/projects/code/lapkt-installation$ tree -L 4
.
├── include
│   └── lapkt
│       └── novelty
│           ├── atom_evaluator.hxx
│           ├── base.hxx
│           ├── features.hxx
│           └── multivalued_evaluator.hxx
└── lib
    └── liblapkt-novelty.so

This of course is orthogonal to what you say, @nirlipo.
The thing I don't like about this approach... is that we would have the code in separate repos?
And this might create too much overhead in terms of keeping different versions of the module sync'd.
I like however the idea of the install script, which I have already written, and which is somewhat independent of using the approach above or not. It can be used as a quick way to install / uninstall different LAPKT versions.

[gfrances]

In any case, it clearly seems reasonable to me to maintain the division you mention, Nir.
The poing would be whether we consider e.g. the very-specialized bfws falls within the category of "general algorithms" or within the novelty module...?

[miquelramirez]

The idea of having specific repos for each module is interesting @gfrances - especially when it comes to making public specific bits and pieces, while leaving private others which are still being worked on and haven't been published.

The concern regarding overheads is a real one, but perhaps could be bridged with automation? Perhaps we could have an "empty" skeleton lapkt repository, with scripts that bootstrap the whole thing via git submodules

https://git-scm.com/docs/git-submodule

how does this sound?