Verified :-)
On Jan 5, 2011 10:53 PM, "Malte Helmert" <downward.issues@googlemail.com>
wrote:
>
> Malte Helmert <helmert@informatik.uni-freiburg.de> added the comment:
>
>> Temporary fixes like this have a tendency to stick around for a while, so
I'll
>> add some additional central documentation to the website in the meantime.
>
> http://www.fast-downward.org/OptionCaveats
>
> Erez, it would be great if you could verify this one more time.
>
> Closing this one! :-)
>
> ----------
> status: in-progress -> resolved
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue120>
> _______________________________________________________

> Temporary fixes like this have a tendency to stick around for a while, so I'll
> add some additional central documentation to the website in the meantime.

http://www.fast-downward.org/OptionCaveats

Erez, it would be great if you could verify this one more time.

Closing this one! :-)

Wonderful, that means we're done. :-)

We'll have to simplify this eventually, for which I've opened issue190. (I've
nosied Erez and myself; Gabi and Silvia, please add yourself if interested.)

Temporary fixes like this have a tendency to stick around for a while, so I'll
add some additional central documentation to the website in the meantime.

On Wed, Jan 5, 2011 at 9:43 PM, Malte Helmert <
downward.issues@googlemail.com> wrote:

yes, except it does not have to be set explicitly (the default is 0)

yes

yes, except it does not have to be set explicitly (the default is 0)

yes, except it does not have to be set explicitly (the default is 0)

yes

yes - I'll update the documentation

>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue120>
> _______________________________________________________
>

-- 

--------------------------------------------------------------
"Adventure is just bad planning."
    Roald Amundsen
    Norwegian Arctic & Antarctic explorer
    (1872 - 1928)
--------------------------------------------------------------

Thanks, Erez!

I'm still confused about how exactly to specify the cost type with the landmark
heuristics and in combination with the synergy.

There are four different options involved:

 (1) lm_cost_type of the landmark definition
 (2) cost_type of the landmark definition
 (3) cost_type of the synergy definition (if using synergy)
 (4) cost_type of the landmark heuristic definition (otherwise)

Here is my understanding of when which option is relevant:

 (1) affects the LM heuristic and must be set iff we use the LM heuristic
     with admissible=false. This is independent of whether we use the
     synergy or not.
     Is this all correct?
     What happens if we use this with admissible=true? Is the option
     simply ignored?
 (2) affects the FF heuristic and must be set iff we use the synergy.
     If we don't use the synergy, this has no effect.
     Is this all correct?
 (3) affects the LM heuristic and must be set iff we use the LM
     heuristic with admissible=true together with the synergy.
     Is this all correct?
     What happens if we use the synergy together with
     admissible=false? Is this option simply ignored?
 (4) The scope of this is currently not documented. My *assumption*
     based on the above is that this is only used with
     admissible=true, and if admissible=false, then (1) is used
     instead. Is that correct?

I updated the docs

OK, the only thing that needs to be done now is to mention the cost_type and
lm_cost_type options in the documentation for the heuristics and the synergy.

I've changed my mind on this: we should update the documentation immediately,
even if this is not in master yet. This means the doc will be out of sync for
another week or so, but that's better than having to add all these changes later
when we might forget about some changes we made. (I already forgot about quite a
few.) For the things I did recently (adding action support to various heuristics
etc.), I already updated the documentation.

So can someone add the cost_type and lm_cost_type options to the docs? Not sure
if we should explain the cost_type option only once, at the top of the
HeuristicSpecification page, or if it should be mentioned for each heuristic.
The latter would be good because people can see the relevant options for a
heuristic at a glance, but we don't want this to be repetitive. Maybe the best
solution is to explain the option once near the top of the page, and then just
very briefly mention it for the individual heuristics.

In summary, the remaining TODOs are:

 * Add the new options to the heuristic docs.
 * Add the new options to the synergy docs.
 * Add the new options to the command line examples, specifically the one
   that explains how to emulate LAMA.

issue175 is done - Malte, you need to review and merge

> An alternative way of treating costs can be chosen for heuristics, but not (yet)
> for the search algorithms, so e.g. we currently don't support ignoring costs in
> the actual search (i.e. for the g values). If someone could implement this
> soonish, this would be great, but if not, we'll have to live with it.

Erez is working on that (issue 175).

> I wonder if we should change the behaviour of cost_type=2 to *only* add 1 if
> the problem has any actions with cost != 1. This would then match LAMA's
> behaviour on the IPC 1998-2006 tasks. Opinions?

This is now implemented.

> You're right that using 1 or 2 in the unit cost case doesn't matter. The
> problem is the other way round, when tasks having non-unit costs are used.
> Malte stated in an earlier post that the default behaviour of the planner is
> to ignore costs when no command-line options are given. Is this true?

No, the default is to use the actual action costs, as Erez said. Some of the
*heuristics* currently ignore action costs because they don't support them, but
we're working on that.

An alternative way of treating costs can be chosen for heuristics, but not (yet)
for the search algorithms, so e.g. we currently don't support ignoring costs in
the actual search (i.e. for the g values). If someone could implement this
soonish, this would be great, but if not, we'll have to live with it.

I wonder if we should change the behaviour of cost_type=2 to *only* add 1 if the
problem has any actions with cost != 1. This would then match LAMA's behaviour
on the IPC 1998-2006 tasks. Opinions?

The default is to use pure action costs (this is so optimal planning would work 
without any switches).

You're right that using 1 or 2 in the unit cost case doesn't matter. The
problem is the other way round, when tasks having non-unit costs are used.
Malte stated in an earlier post that the default behaviour of the planner is
to ignore costs when no command-line options are given. Is this true? If
yes, then it would be better to change this so that "costs + 1" is the
default, so that we use action costs when they are present in the input
rather than ignoring them.

For this specific issue, if all actions are unit cost, and we make the +1 
adjustment, then all actions cost 2, which is basically the same as multiplying 
w (of wa*) by 2, so I don't think that will matter too much.

But this is a more general issue - how should we handle the input adaptively?

For example - LM-CUT does not support actions with costs > 1000. Then the 
selective-max configuration should only use h_LA with such high cost actions. 

This is something we should think about, but probably not now.

Axioms are always treated as cost 0 in LAMA, no matter what cost setting is
used. (Sorry for the delayed response due to me being away from the code
during the holidays.)

One question back to you and Erez: as far as I understand, you have now
implemented the different cost settings in FD, and they are triggered via
command-line options. LAMA actually does not do this via command-line
options, it automatically uses "costs + 1" if the "minimise costs"
requirement is given in the PDDL input, and otherwise unit costs are used.
Do you think it would make sense to change the default behaviour of the
FD-implementation to be the same as LAMA? I.e, have it react to the input
requirements if no command-line options are given? Because if we feed tasks
with action costs and the "minimise costs" requirement to the planner, we
would expect the default behaviour of the planner to be that it uses those
action costs rather than ignoring them, don't you think?

I've opened a new issue for this: issue175
I'll work on it today

OK. Erez, one way to support this would be to also add a cost_type option to the
search algorithms. Can you do that?

Whether action costs are used or not is a global setting and takes effect
both in the heuristics and the search algorithms.

In detail, when action costs _are_ used, they are used both in the
heuristics and search algorithms, the only difference being that the
heuristics additionally do +1 whereas the search algorithms don't.
Analogously, when _not_ using action costs (i.e. when using unit costs),
this is the case both for the heuristics and the search algorithms. So, the
problem you describe, Malte, that g-values take over compared to h-values,
does not occur.

I'll get back to you about the axiom question once I'm back from my
holidays, as I'll have to check the code to be sure.

Exactly
On Dec 31, 2010 7:13 PM, "Malte Helmert" <downward.issues@googlemail.com>
wrote:
>
> Malte Helmert <helmert@informatik.uni-freiburg.de> added the comment:
>
> Ah, OK, so to affect both heuristics, you need something like
>
> # ./downward --heuristic
>
"hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=1,lm_cost_type=1))"

> --search "lazy_greedy(hff,hlm)" < output
>
> Thanks!
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue120>
> _______________________________________________________

Ah, OK, so to affect both heuristics, you need something like

# ./downward --heuristic
"hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=1,lm_cost_type=1))" 
--search "lazy_greedy(hff,hlm)" < output

Thanks!

It works. To adjust the FF heuristic's cost_type, you need to pass it to the 
landmarks graph (that's the ugliest hack there).

Try:

./downward --heuristic 
"hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=1))"  --search 
"eager_greedy(hff)" < output

OK, I added some things that went missing on the first merge with default, but
this still does not work as intended: the LM heuristic of the LM_FF synergy now
correctly handles the lm_cost_type option, but I can't seem to get the FF
heuristic of the synergy to do the same thing. Erez, can you give me a complete
command line for that and check that the current code in ipc is correct?

Yes, definitely looks like a merging problem. (Related to the merge conflict
thing I wrote about yesterday.) Oh well. :-( I'll look into it.

It was introduced in c441fcefeeac
and it's definitely in my bitbucket repository.

I merged everything that was pushed to the erez repository (just checked the
graph again to be sure), so the two main possibilities are

1) you forgot to push this
2) something went wrong when merging

Please check in which of your local revisions this code was introduced, check
that it was pushed to bitbucket, and tell me the revision number (the long hex
number, not the short decimal one).

The correct way to consider action cost with the inadmissible version of the 
lmcount heuristic is:
   "hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,lm_cost_type=1))"  ...
However, I just pulled the latest version from downward-ipc, and noticed that 
the code that parses this is not in there. Specifically, I noticed that it's 
missing from the LandmarksGraph::add_options_to_parser method, but maybe from 
other places as well.

And a question to Silvia: when treating actions as unit cost in the heuristic,
do you really still treat them with their regular cost in the search algorithms?

In the greedy best-first run that won't make a difference of course, but in the
weighted A* run this can mean that in domains like ParcPrinter we get g values
in the 100000s and small h values, so that h doesn't effectively matter much
anymore and we essentially do a uniform cost search.

Hmm, more work to do. I tried this out in various configs, but the cost_type
option seems to have no effect:

./translate/translate.py ../../benchmarks/parcprinter-08-strips/p01.pddl &&
../preprocess/preprocess < output.sas && ./downward-1-debug --heuristic
"hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true),cost_type=1)" --search "iterated(
                              lazy_greedy(hff,hlm,preferred=(hff,hlm)),
                              lazy_wastar(hff,hlm,preferred=(hff,hlm),w=5),
                              lazy_wastar(hff,hlm,preferred=(hff,hlm),w=3),
                              lazy_wastar(hff,hlm,preferred=(hff,hlm),w=2),
                              lazy_wastar(hff,hlm,preferred=(hff,hlm),w=1),
                              repeat_last=true)" < output

This should treat the actions as unit cost for the purposes of the heuristic,
but according to the output it doesn't.

Same thing with this config:
../translate/translate.py ../../benchmarks/parcprinter-08-strips/p01.pddl &&
../preprocess/preprocess < output.sas && ./downward-1-debug --search
'lazy_greedy(lmcount(lm_rhw(),cost_type=1))' < output

Erez, I think I am doing something wrong, but I don't know what. I guess this is
related to the fact that the cost_type stuff for LM heuristics is implemented
somewhat hackishly?

Re msg944: merged. The change to the line I quoted in msg938 was still missing,
so I added it in changeset 8442581520de.

So we still need to:

(2) Update documentation (especially for LM heuristic, where we changed
    behaviour: costs were ignored by default before, not any more)
    => deferred until after IPC

(3) How to handle axioms: msg937
    => would like some input from Silvia there

(4) Properly deal with pure action cost support and zero-cost actions;
    see msg512 and msg513
    => ditto

(2): You're right; this should be left alone for now. I don't think we need a
copy; maybe just an extra documentation page somewhere on the wiki that explains
the differences in a few sentences. "UnmergedDocChanges" or whatever.
We can make this page private if you prefer.

(1): I tried to merge this but failed due to too many merge conflicts caused by
whitespace differences. Will try again tomorrow when I'm rested.

I fixed (1) and pushed it to my repository.

About (2) - I'm not sure changing the documentation now is a good idea, since 
it's not in the public repository. Shall we make a copy somewhere?

Merged, since the bulk of the functionality is done. However, I'm leaving this
open since four smallish TODOs/issues remain:

(1) Question about optimal cost partitioning: msg938

(2) Update documentation (especially for LM heuristic, where we changed
    behaviour: costs were ignored by default before, not any more).

(3) How to handle axioms: msg937

(4) Properly deal with pure action cost support and zero-cost actions;
    see msg512 and msg513

Erez, in landmarks/landmark_cost_assignment.cc:
            row_ub[op_id] = op.get_cost();

Shouldn't that use the adjusted cost?

Silvia, one question (fortunately not relevant for the IPC): in the settings
where all actions are treated as "unit cost" or as "actual cost + 1" in the
heuristics, what cost do you assign to axioms in the heuristics (e.g. h_add for
the FF heuristic), 0 or 1? (I'm assuming that you treat them as cost 0 in the
case where all actions are treated with their actual cost in the heuristic.)

I made the changes from the code review, and pushed them.

I checked some tasks from parcprinter and openstacks, and the landmark cost 
adjustment seems to work.

Thanks! I had very few remarks, but it'd be great if you could incorporate them
since even code planned to be temporary has a nasty tendency to stick around. ;-)

I'll then merge this into the IPC repository.

Uploaded to rietveld:
http://codereview.appspot.com/3813041/

BTW, your changes to the landmarks code suggest to me that costs are ignored by
the LM heuristics with admissible=false in our current master repository, so
I've updated the documentation accordingly.

BTW, your changes to the landmarks code suggest to me that costs are ignored by
the LM heuristics with admissible=false in our current master repository, so
I've updated the documentation accordingly.

Hi Erez, I have some comments (nothing too big, but still).
Can you open a Rietveld issue for this?

I implemented this in my repository.
It's really ugly, but seems to work.

I had to add two flags to the landmarks graph:
lm_cost_type - controls how landmark costs are set (for lmcount inadmissible)
cost_type - controls how the synergy FF treats action costs (only for LAMA/FF 
synergy).

In addition, the lmcount heuristic has a cost_type flag, which only does 
something when uniform cost partitioning is used.

As I said, it's ugly, but it works.
I would think twice about integrating it into the main repository, we might just 
want to use this for the competition.

> Done.

We discussed over Skype that it'd be better to make this a per-heuristic option.
Erez will make that change, then I'll integrate it, and then you can start the
experiments you mentioned before, Silvia. Any deadline on that?

> Along the way, I discovered that very few heuristics even look at action costs:
> h^m, landmarks, exploration (landmark's FF), LM-CUT

Makes sense -- Silvia added action cost support for the landmark code and its
relaxed exploration, and apart from that, I think that's precisely the list of
heuristics we added after adding action cost support.

Thanks for adding this to issue91!

Done.

Along the way, I discovered that very few heuristics even look at action costs:
h^m, landmarks, exploration (landmark's FF), LM-CUT

I think they all respect action costs (I'm not sure about exploration).
I'll add this info to issue91

> cost = g_use_metric ? op_cost + 1 : 1;

IIRC, the search code compensates for this by subtracting 1 at some point.
Silvia can tell you more.

> However, we can avoid this with my modification, if instead of having a
> global cost_mode var, we pass it as a parameter to the get_cost() method, and
> always use the normal mode from the search code.
> If you think this is a good idea, I can do this.

Yes, I think that would be good.

Actually, they are used everywhere.
The modification takes place in the code that reads the sas file

cost = g_use_metric ? op_cost + 1 : 1;

However, we can avoid this with my modification, if instead of having a global 
cost_mode var, we pass it as a parameter to the get_cost() method, and always 
use the normal mode from the search code. 
If you think this is a good idea, I can do this.

Hi Erez, I don't think this does what LAMA does. In LAMA, the modified action
cost values are only used within the heuristics, not within the search
algorithms. (Right, Silvia?)

I implemented an ugly hack for LAMA-style actions costs, in branch issue120 in my 
repository.
I know it's ugly, but we might want to use it for the competition anyway.

Agreed.
Let's put this on hold for now.

Hmmm... I had a look at the code for a moment and could not find a way to
implement a common set of options for a bunch of heuristics that is not
butt-ugly. I think there should be a nicer way of doing this, but that would
require some refactoring in the options code first, which I think we were
planning to do anyway.

(An alternative which I wouldn't mind trying out would be to implement this as a
problem transformation from the start and only give the heuristics a new
optional "problem" parameter, but that would require rather massive code changes
in different places. We can maybe discuss this option in person when Erez is in
Freiburg.)

Sound good.

I think you didn't understand my idea exactly, but let's do as you suggested - 
look at the two implementations and see which one looks better.

I don't like this; since this adjustment is purely for purposes of the
heuristic, it should live in the heuristic. There's no reason why operators
should care about this. Also, this would separate the code that handles the
command-line arguments for this from the code that implements the functionality.
(Unless you want the command-line arguments to also be implemented by the
Operator class, but that would be really ugly, I think.)

I'd much prefer the solution I've been proposing from the start, putting this
info into a heuristics base class. This also makes sense because it would couple
the code that parses the command-line options for this with the code that
interprets those options, rather than having one in some heuristics-related
class and the other in the operator class.

We could also implement both solutions and compare which one looks better. I
could probably spare some time tomorrow or so to implement the solution I prefer.

I think the best way of implementing this now is to add a new method to 
Operator:
int get_adjusted_cost(int method)
which implements these options (as a function of the method parameter).
We then need to replace the calls to get_cost() with a call to the new method 
with the correct parameter.

I don't like to mess with the really basic classes without checking first - so 
is this a good idea?

Problem transformation split off into the new issue125. (Please nosy yourself
there if interested.)

Actually, there are a bunch of useful things that could be done by problem
transformations or problem adapters. Some of them could be under the control of
the user, others could be under control of the heuristics.

Example under control of the heuristics: some heuristics (at least h^cea)
compile the goal away to simplify their implementation. This could be one kind
of general problem transformation that is implemented in such a way that it is
also useful for others who want it. This is best implemented using some kind of
adapter that doesn't modify the original problem (since we don't want to compile
goals away everywhere -- some people, like the goal count heuristic, might like
having the original goal around) or copy the problem (since that's a waste of
time and space).

An example under control of the user would be a transformation that compiles
landmark tracing into the problem so that the heuristics can than make use of
the enriched problem, as in Matthias's Studienarbeit or the paper by Carmel,
Michael and Sagi.

I think there's a lot of potential there, but I'd see that in beyond-1.0
territory and would prefer sticking to the base class approach for now. If there
are other preferences, I'm open to discussion though.

I think that logically it belongs to the heuristic because it's the heuristic's
choice whether it wants to consider action costs or not. That is, I want to be
able to say as a user that I want a combination of the FF heuristic ignoring
action costs and the h^cea heuristic respecting action costs.

Of course we don't need to implement code for this in more than one place --
that's what base classes are for.

It's possible to add additional indirection here to delegate to a problem
adapter class, which would be an example of delegation instead of inheritance
which is often a useful design pattern, but only when the added flexibility is
actually useful.

If we can think of other transformations of a similar kind that we want to
support, or if we want to support such transformations in a plug-and-play
fashion, that's worth considering. I'd first try out a simpler baseclass-based
implementation though, and then see how much we like the result.

I think the best (but maybe not easiest ) way to implement this, is to
create a Problem class, and have everything work on the Problem.
Then we could create variants of the problem, each according to a different
action cost method, and "feed" different problems to the heuristic. This
means we won't have to support different action cost methods (or any other
type of transformation) for each heuristic individually.

Erez.

On Thu, Sep 9, 2010 at 4:00 PM, Malte Helmert <
downward.issues@googlemail.com> wrote:

>
> Malte Helmert <helmert@informatik.uni-freiburg.de> added the comment:
>
> Thanks for pointing this out! The code now has fairly generic support for
> things
> like that; I guess we could do this using an option string like
>
>  --search 'tiebreaking(hff(costs=pure), hff(costs=unit))'
>
> (as an example for the case of the FF heuristic), where the "costs" option
> would
> still need to be implemented but the generic tie-breaking mechanism is
> already
> in place.
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue120>
> _______________________________________________________
>

-- 

--------------------------------------------------------------
"Adventure is just bad planning."
    Roald Amundsen
    Norwegian Arctic & Antarctic explorer
    (1872 - 1928)
--------------------------------------------------------------

Thanks for pointing this out! The code now has fairly generic support for things
like that; I guess we could do this using an option string like

  --search 'tiebreaking(hff(costs=pure), hff(costs=unit))'

(as an example for the case of the FF heuristic), where the "costs" option would
still need to be implemented but the generic tie-breaking mechanism is already
in place.

Implementing the "pure action costs" option was a bit tricky, at least the way I
did it for the JAIR experiments. As we experienced very bad performance using
pure costs in the greedy best-first search (e.g., given actions that cost 0), we
decided to add tie-breaking on distance. So, the next state to be selected for
expansion by the search is one with minimal h-value according to action costs,
but if there are several such states, choose among them one with minimal h-value
according to goal distance (i.e., counting each action as 1). 

I had to make several changes in the heuristic computations and search
algorithms to implement that functionality, so we might not want to do that. Of
course we could implement the "pure action costs" option without the
tie-breaking, but the main outcome of that would probably be just a
demonstration that it's not a good idea :)

Thanks, Silvia. I think it is useful and not too much work to support all three
ways of handling action costs.

There are not actually three different ways of handling action costs in LAMA,
there is only one way implemented in the standard planner. (The other two
methods were implemented in an experimental branch for the JAIR paper only.)
Though LAMA does behave differently depending on whether cost-based planning is
desired or not.

If the "minimise action costs" requirement is given in the input task, then LAMA
uses the action costs plus 1 (heur_cost(a) := cost(a) + 1). 
Otherwise, if no "minimise action costs" requirement is given, LAMA does
traditional planning without action costs, i.e. it counts each action as costing
1 (heur_cost(a) := 1).

In cost-based planning, the modified action costs (+1) are used only in the
calculation of the heuristics, thus for the h-value associated with states. The
g-values in the search algorithms are based on the original action costs.

Split off from issue20.

In LAMA, there are three different way to handle action costs in the heuristics:
 * use them as is (heur_cost(a) = := cost(a))
 * ignore them (heur_cost(a) := 1)
 * set them to the real action cost plus 1 (heur_cost(a) := cost(a) + 1)

Detailed descriptions in Silvia and Matthias's LAMA JAIR paper, which should be
out soon.

Silvia, how are the action costs handled by the actual search algorithms, i.e.
for g values? Does the search always use the proper action costs, or does it
always use the modified costs?

I suggest that we emulate LAMA's handling of action costs at least for the
heuristics in LAMA (landmark and FF), but in the long run also for other
heuristics (see issue91).

For this purpose, it'd be useful to implement the common part (option handling,
a method to query the "effective action cost") only once, in a common base class
for the heuristics that use it.