Awesome. Merged and pushed.

Looks fine to merge. Thanks!

The results are in:
http://ai.cs.unibas.ch/_tmp_files/seipp/issue684-v1-issue684-base-issue684-v1-compare.html

Looks good to me, but to be on the safe side, I'd prefer experimental results on
the configurations affected by this in the driver script. A short runtime (60
seconds) is fine with me if the portfolios support this in a reasonable way.

I took care of your comments. Do you think we can merge this?

Thanks for working on this! I'm done with my comments.

I updated the pull request accordingly. Could you have a look, please?

I wonder if we should have "parent transformations" at all. It seems like a
YAGNI violation, and if you want to do multiple transformations, a cleaner
design (in the sense of separating concerns) would be one with an explicit
composite pattern, as in: "transform=chain_transformations(trans1, trans2)". (It
wouldn't have to be called "chain_transformations", of course.)

Without parent transformations, I like the solution with
"transform=adapt_costs(one)", as it would require no further code changes and is
not terribly verbose. We could add convenience wrappers like "ignore_costs", but
perhaps it's better to only start doing that when and if we get annoyed with the
longer syntax.

I chose to do it in one step and created a pull request at
https://bitbucket.org/jendrikseipp/downward/pull-requests/61 .

Before I convert the aliases, portfolios and the code in portfolio_runner.py to 
the new syntax, I'd like to make sure we're happy with the new way of specifying 
cost transformations.

Currently, the syntax is A="transform=adapt_costs(cost_type=one)". Since 
cost_type=normal is not really needed, we could also provide two explicit task 
transformations "use_unit_costs" (or "ignore_costs") and "use plus_one_costs" (or 
similar). Then the syntax would be a little less verbose: 
B="transform=use_unit_costs()". Another alternative would be to move the 
cost_type parameter to the front of adapt_costs' arguments (currently it comes 
after the parent transformation argument) and make it mandatory, allowing us to 
omit the "cost_type" key: C="transform=adapt_costs(one)". I have no strong 
preferences. What do you think?

I would do all in one step because I don't think it will be a huge patch, and
in my mind this belongs together. Also, only having one way to specify cost
transformations will make everything conceptually much cleaner. But if you
prefer to do multiple steps, that's OK with me, too.

If we remove the cost_type commandline option, then yes, get_task_from_options() 
can go away. If we only remove the Heuristic::cost_type member, then I think we 
still need the get_task_from_options() mechanism. I think we can do these two 
changes in two stages. This would allow us to change config strings later, once 
we're really confident with the design. What do you think?

If I understand/remember correctly, the only reason why get_task_from_options
exists is because there are two ways to specify modified tasks: directly, or via
cost_type. Hence, once cost_type goes away, it seems that get_task_from_options
is no longer needed and should be removed. (But there may be other aspects I'm
not remembering.)

When the landmarks code uses the task interface (issue551), we can remove the 
cost_type member and get_adjusted_cost() from Heuristic. 

The only code that uses the cost_type passed to heuristic components is then 
get_task_from_options(), but the function will ignore it when a task is given. I 
propose to make the cost_type optional for objects passed to this function. Then 
we don't have to add CostType::NORMAL to Options objects in various places, just 
to let it be ignored by get_task_from_options().