It’s been a while since I have made a PhD post here…

Anyway, lately I’ve been working on multi-module slot optimisation. This means optimising the order of modular rules when using modules for multiple conditions simultaneously. For example, the case of (clear a) (clear b) => (move a b). This isn’t a problem when the modules are optimal (the above -> move floor rule), but when the module is created automatically, it tends to create rules which work fine when solving the clear goal, but badly when solving multiple goals.

For example, the above -> move rule for clear works fine, but a side effect of it is that it also has the chance of covering a second block when clearing it. So, an extra modularisation step is used when combining modules to create a new module file which finds the best combination of module rules for solving the particular goal.

Looking at early results, it seems to be working. A final generator file using the somewhat optimal rules results in this:

(moveFloor{((above ?X ?_MOD_a) (clear ?X) (test (<> ?X ?_MOD_a)) (block ?X) (block ?_MOD_a) => (moveFloor ?X):1.0)}),0.4985128077042666

(move{((on ?X ?_MOD_a) (clear ?X) (clear ?Y) (test (<> ?X ?_MOD_a ?Y)) (test (<> ?_MOD_a ?Y)) (block ?X) (block ?_MOD_a) (block ?Y) => (move ?X ?Y):1.0)}),1.3671816823825072E-4

(moveFloor{((above ?X ?_MOD_b) (clear ?X) (test (<> ?X ?_MOD_b)) (block ?X) (block ?_MOD_b) => (moveFloor ?X):1.0)}),0.5013099762800816

(move{((on ?X ?_MOD_b) (clear ?X) (clear ?Y) (test (<> ?X ?_MOD_b ?Y)) (test (<> ?_MOD_b ?Y)) (block ?X) (block ?_MOD_b) (block ?Y) => (move ?X ?Y):1.0)}),4.04978474135572E-5

A bit gibberishy, but basically it says the moveFl rules are best.

Time to try it again with optimal rules for both move and moveFloor.