cleanups and refine readme

[ssardina]

Started elaborating the README to track the sources of each domain. There are actually references in papers that are wrong (on the sources).

Still many domains (particularly many in the PRP repo not in the PRP paper) are yet to track down.. 😉

Also:

• factor out probabilistic interesting into their own folders
• added main entry to script catalogue.py
• added some initial context (mostly on the oneof ND-extension) and FOND planners around (sure there are missing ones)

[ssardina]

@haz did quite a bit of work and history tracking. Learnt quite a few things... 😉

Let's discuss here what we want to do. I think it is a great idea to put some order on this; I've seen in papers that it is all a bit disorganized on where domains come and what were the motivations when introduced.

Regarding #1, I think it would be good to have collections for everything that makes sense. For example, the collection "PRP paper" would be built from 3 collections: IPC6 fond track collection, probabilistic interesting (3), and prp-new (the few ones you reported in the paper taking from probabilistic track). Then there are a lot of prp-extended I guess which are like the prp-new but not reported in paper.

What do you think? There are many ways to do this, but is badly needed AND would be good to track the sources of as many domains as possible, if not all.

[haz]

Collections of collections? Not sure I'd go there, if for no reason other than "it breaks the model of API.planning.domains hierarchy" :P . But having (for posterity sake) a collection for "the benchmarks used in PRP'12", could be useful. What really gets tricky is knowing when to fork -vs- just update things. E.g., do we keep the buggy original version of the tireworld where you could just ghost your way to an easy solution? Do we keep around the unsolvable instances of benchmarks, many of which are at low parameter values in the problem generation process? Etc.

[ssardina]

Regarding the hierarchy, I am not sure if you are referring to the way of implementing this OR the actual idea of being able to somehow get a handle to some set of meaningful set of domains, e.g., "instances used by FOND-SAT" vs "instances introduced by FOND-SAT, also called it "risky-nondeterminism"", say...

Or "instances used by PRP12" vs "instances from IPC-6" (subset of the first ones)

Regarding fork vs update, I think we need to do the call per case, there is no blanket rule. In the case of tireworld, I would keep both separately. We just need to seriously document (in readme and maybe domain file) all that.

Finally, it would be gold to be able to know what instances of every domain are indeed unsolvable. We would need a way to exact "all", "solvable", "unsolvable", yes. That would be "the best"way. If we want the easy way, then there are other options ha! 😉 agree?

[ssardina]

@haz , have progress this more. Did a lot of cleaning and documentation.

I think almost all domains can be traced-back and know a bit their motivations

We may want to think about #5 , there seems to be some "garbage" domain versions that I think we want to remove (e.g., planner specific)

[haz]

Ya, I think your suggestions in #5 make plenty sense. Want to make those changes here, or in a new PR?

[ssardina]

Let's review and close what was done so far, then we continue with #5 in another new PR

[haz]

So ready for review?

[ssardina]

yes, but I don't have permissions to request review I think.

[haz]

An amazing bit of FOND history research here! Only one small thing jumps out to me...