sjolicoeur / crisp-nlg Goto Github PK

... so it can be seen from anywhere and downloaded by Matthew.

If a tree name does contain a hyphen, it aborts with a null pointer exception.

- in Java
- using (new?) methods from Domain and Problem to save on the preprocessing
with the constant declarations etc.
- have a main program that then writes Domain/Problem to disk
- and another that feeds it into the planner directly without further need
for parsing.

In at least some of the crisptest examples, at some point, step(step1) was
not mutex with ~step(step1) in the first state.  Can I reproduce this, and
if yes, why is it and how do I fix it?

1. Initial state: P(a)
2. Only action: A(x); precondition: P(x); effect: ~P(x), Q(x)

This should make ~P(a), ~Q(a) mutex in the next state, but it doesn't.  

Mod6 requires a plan of length 10.  However, the planner starts search on
length 10 with a -step9 action, and then takes a long time to realize that
this doesn't work.

Is there any way (stronger mutex relations?  more than binary mutexes?) to
make it explore the -step10 action first?

How is it possible that SHOW_TIMES_PER_DEPTH reports hundreds of failures
but 0 to 1 nogoods?  Do we really collect this few nogoods, or is the
report wrong?

Currently, the LazyGP planner will continue expanding the planning graph
indefinitely for unsolvable inputs, until it hits the prespecified plan
length limit.  Instead, the planner should recognize that further expansion
makes no difference, and stop.  The criterion for stopping was explained in
the planning textbook -- was it no further changes to the nogood table? --,
and I should implement it some time.

It finds no plan involving the following action:

 (:action move
      :parameters (?from - position  ?pos2 - position  ?ori - orientation  )
      :precondition (and (player-position ?from)  (player-orientation ?ori) (adjacent ?from ?pos2 ?ori) 
(not-blocked ?from ?to) (not-alarmed ?to))
      :effect (and  (player-position ?pos2) (not (player-position ?from)))
   )

However, it does find one if the "player-orientation" and "adjacent"  
preconditions are reversed. 
This should not happen, and is clearly a bug in the method that computes 
applicable action 
instances.

On mod6, the shortest plan needs 10 steps.  However, the planner wastes a
lot of time on searching for plans of shorter lengths -- in mod6, it spends
50% of the runtime on search for length 9 alone.  Find a way to estimate
the correct plan length so this doesn't happen.

There's an increasing number of options that control the search and switch
the debugging output on and off.  It would be convenient to have these on
the command line.

What steps will reproduce the problem?
1. svn checkout http://crisp-nlg.googlecode.com/svn/trunk/Code/crisp
2. mvn install assembly:assembly

What is the expected output? What do you see instead?

The system complains about missing `crisp.properties` file. I tried building FF 
obtained from `https://fai.cs.uni-saarland.de/hoffmann/ff.html`, then copying 
`crisp.properties.example` file over and modifying, but got and error saying FF 
unexpectedly terminated.

The link to FF also seems outdated.


What version of the product are you using? On what operating system?
Ubuntu 14.04 32 bit, Maven 2.2.1, Java 1.7.0_76

This method combines substitutions rather heavy-handedly at this point,
which is a significant part of the planner's runtime.

The way that extensions of concepts are computed right now is totally stupid. 
It should really be 
something based on BitSetSet, where conjunction just amounts to intersection 
and quantification 
amounts to following in-edges backwards. Doing this efficiently would speed up 
both the positive 
and the bisim algorithms.