Merged. I only made a small change to make the comparison function local to the
module and take const pointers.

Thanks for spotting and fixing this!

In that case, it's already in my repository

> But also, I don't think I can use operator<, since I'm sorting a vector of 
> Proposition*, and I don't think I can override the comparison of pointers.
> Or am I missing something?

No, you're right; I didn't see that. Even if you could override that, it'd be a
bad idea. ;-) So separate comparison function is fine.

Ignore my last, hash_unary_operator is for hashing a vector.
But also, I don't think I can use operator<, since I'm sorting a vector of 
Proposition*, and I don't think I can override the comparison of pointers.
Or am I missing something?

Should I also do this of the hash function (hash_unary_operator)?

PS: Better to define operator< than use a separate comparison method.

Looks good. Can you prepare an issue167 branch?

I think I found the culprit.
Line 132 in relaxation heuristic.cc:
sort(op.precondition.begin(), op.precondition.end())

When I add this:
static bool compare_props(const Proposition *p1, const Proposition *p2) {
    return p1->id < p2->id;
}
and change the line to
sort(op.precondition.begin(), op.precondition.end(), compare_props);

It seems to make FF deterministic.

The FF heuristic's implementation is not deterministic, and depends on other 
things going on in memory.
Example:
For depot:pfile18, running    ./downward --heuristic "h=ff()" --search 
"eager_greedy(h,preferred=(h))" gives an initial h value of 65.

Running  ./downward --landmarks "lmg=lm_rhw()" --heuristic "h=ff()" --search 
"eager_greedy(h,preferred=(h))" < output  (which does the same except for 
creating a landmarks graph first) gives an initial h-value of 63 or 64

I think this is because somewhere, some hash is based on memory addresses (even 
though I noticed an attempt to get rid of this in hash_unary_operator).