-
Notifications
You must be signed in to change notification settings - Fork 1
Roadmap
(C&P parcial mail Héctor):
Para acercarnos a los running times del código de Nir as much as possible. Ver rapidamente el x10 (or aprox) en node generation time FS vs Nir; y ver que pasa con Parking que es el unico dominio de IPC 2014 donde parece haber un significativo al correr BFWS(w_{#g},#g) en FS vs. Nir. Con eso claro (no hace falta competir en tiempo con el codigo de Nir; solo entender si esta quedando alguna optimizacion clara/facil fuera)
En el caso de FS, primero usando la implementación FF de APTK, después la nativa, por si acaso. Ver si FS y Nir's code siguen en sync al movernos a f5; es decir w = w_{#g,R}, en ambos casos con R relajado (no simulado).
Una vez que FS y Nir's code esten en sync con R relajado .. metemos R simulado en f5 de FS, tratando de no alejarnos mucho en performance de de f5-FS con R relajado. Para esto, Nir tiene algunos hacks a tener en cuenta; ej, 1) si muchos atomos .. computar w de 2 niveles solo, y por tanto no usar IW(2) si no IW(1), 2) Si IW(2) o IW(1) no alcanzan ningun goal .. no usar ninguno; es decir, volver dinamicamente a lo de ahora, BFWS(w_{#g},#g) (en otras palabras: problemas que ahora estamos resolviendo con BFWS(w_{#g},#g), los queremos seguir resolviendo .. en lugar de caernos computando IW(k) ..)
Con todo lo de arriba, mostramos que no big penalty payoff for ignoring action structure/planning with simulations. EL otro tema es mostrar el expressive/computatoinal payoff; y ahi vienen los 2 puntos que mencionaba abajo. Como dice Guillem: 1) podemos meter esos problemas en FS con procedimientos, y/o 2) considerar extensions de Fstrips (reactions, axioms, etc) para modelar esos problemas de manera mas elegante.
Debido a que los tiempos se acortan, yo creo que 2 esta complicado, y es preferible usar FS as it is (ej, reactions se pueden meter con boolean flag -- time for action/time for reaction; y axioms via procedures) .. y no complicarse demasiado con estos ejemplos, que seran solo ilustrativos (no compararemos performance con otros planners .. ya que en principio, es dificil modelar esos problemas con otros planners ..)
-
uno puede demostrar luego que el performance del bfws-sim se puede mejorar usando mejores encodings. Ej si Tetries y X se lo modela de otra manera, en lugar de resolver X uno resuelve Y > > X, estaría bien y sería otra manera de demostrar el punch (igual, Tetries y otros CSP-like problems .. no serán particularmente buenos para este enfoque vs. SAT approach etc; aunque posiblemente los del bench set no sean grandes y/o sutiles)
-
Last: necesitaremos demostrar alcance del planner en dominios que no sean facilmente modelables sin procedimientos. Ejemplos que me vienen a la cabeza:
- pacman (comer pills while avoiding phantoms that follow deterministic strategy -- eg move greedily toward pacman);
- predators prey (2 predators have to "corner" prey that follows det strategy);
- pong (hit pucket eg 5 times; discretized time for decisions; discrete speeds to choose)
Miquel ya trabajó con versión de este ultimo; quizas tenga otros dominios relevantes de hybrid planning (si son sencillos, entendibles, visualizables .. mejor; tampoco necesitamos mas que 3-4 en total, incluso hasta podríamos incluir el fs encoding + description of the procedures if any).