I'm closing this because it looks like the originally reported issue on
blocksworld wasn't a bug but the FF heuristic acting up.

I'm onto the issue in trucks-strips, but this really looks like it belongs to
issue7, so I'm moving the discussion there.

Very interesting observation! This would explain a number of oddities I've seen
in Trucks. I'll have a look.

Michael and I noticed another thing with the new translator. 
In the trucks-strips domain, using the old version of the translator, effects 
like  -1 --> 0  were created, and with the new version, this changed to  1 --> 
0.

This is fine, but when we looked at the output of the preprocessor, with the old 
version it found only 10 out of 67 variables to be necessary, while with the new 
version 67 out of 67 were necessary.

We think this is because the causal graph construction ignores  -1 --> val  
effects, which happen with the old version and not the new one. I can't say this 
is a bug for certain, but it's definitely worth noting, and possibly thinking 
about changing something (translator, causal graph construction?)

I compared between the translator in r3840 and latest on blocks.

The difference (as far as I could tell) is that in the old version, the effect
of unstack/putdown on clear/handempty went from -1, and in the new version
they go from 1/0 (the correct value). 

Using A*+h_max r3840 is about 20% faster in time (even though they expand the
same number of states).

With FF, we get different heuristic values, which is a bit strange.
For the first blocks problem, we get h(s0)=6 with the old version
and h(s0)=7 with the new version.
However, A*+FF expands less states in the old version.

So it seems that the translator is correct, but the FF heuristic is extremely
sensitive to this for some reason.

This may be related to issue7. Let's revisit this after we've looked at that one.

Attached are the translated outputs for blocks

If this a bad ordering issue, I wouldn't be surprised by weirdnesses like this
at all... or it could be that for some obscure reason the translator decides to
use the dual blocksworld encoding for this instance, but not the others.

Can you attach an archive with all the translated/preprocessed inputs for these
50 tasks for both revisions so that I can take a closer look?

Here are results for all 50 blocks problems.
Take a look at blocks 42.

Sure it's a bug? Can you make a comparison of the old and new revisions on a
larger set of Blocks tasks?

I wouldn't be surprised if greedy BFS on Blocks with the FF heuristic would be
much affected by small things like the order in which operators are considered
since this search configuration is blind to the required goal ordering in
Blocksworld.

Sorry, pressed the wrong button.

with r3840, only 3852 expanded states with the same configuration.
This might be related to all the other translator issues - I have no idea.

With the latest version of the translator, blocks45 is solved after
expanding 41696 states, using configuration zfF.
With r3840 (before the latest change), only