Open gfrances opened 7 years ago
miquelramirez
commented
7 years ago 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
commented
7 years ago 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 notifications@github.com 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 https://github.com/aig-upf/fs-private/issues/48#issuecomment-281076649, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0mVs-J8sGrgKxxfbUVRuN6l3dTTmLnks5reZI8gaJpZM4MGJib .
gfrances
commented
7 years ago 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.soThis 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
commented
7 years ago 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
commented
7 years ago 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?
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".
And the following current components of FS should fall within the "BFWS component / library":
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.