Title remove cost_type from Heuristic
Priority feature Status resolved
Superseder Nosy List jendrik, malte
Assigned To jendrik Keywords
Optional summary

Created on 2016-10-21.17:08:45 by jendrik, last changed by jendrik.

msg5827 (view) Author: jendrik Date: 2016-11-28.12:31:34
Awesome. Merged and pushed.
msg5826 (view) Author: malte Date: 2016-11-28.12:17:11
Looks fine to merge. Thanks!
msg5823 (view) Author: jendrik Date: 2016-11-25.01:12:41
The results are in:
msg5822 (view) Author: malte Date: 2016-11-24.19:16:45
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.
msg5821 (view) Author: jendrik Date: 2016-11-24.19:12:08
I took care of your comments. Do you think we can merge this?
msg5820 (view) Author: malte Date: 2016-11-24.17:15:32
Thanks for working on this! I'm done with my comments.
msg5816 (view) Author: jendrik Date: 2016-11-23.16:03:39
I updated the pull request accordingly. Could you have a look, please?
msg5798 (view) Author: malte Date: 2016-10-28.19:13:37
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.
msg5789 (view) Author: jendrik Date: 2016-10-27.00:02:25
I chose to do it in one step and created a pull request at .

Before I convert the aliases, portfolios and the code in 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?
msg5768 (view) Author: malte Date: 2016-10-21.17:25:21
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.
msg5767 (view) Author: jendrik Date: 2016-10-21.17:20:13
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?
msg5764 (view) Author: malte Date: 2016-10-21.17:10:38
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.)
msg5763 (view) Author: jendrik Date: 2016-10-21.17:08:45
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().
Date User Action Args
2016-11-28 12:31:34jendriksetstatus: reviewing -> resolved
messages: + msg5827
2016-11-28 12:17:11maltesetmessages: + msg5826
2016-11-25 01:12:41jendriksetmessages: + msg5823
2016-11-24 19:16:45maltesetmessages: + msg5822
2016-11-24 19:12:08jendriksetmessages: + msg5821
2016-11-24 17:15:33maltesetmessages: + msg5820
2016-11-23 16:03:39jendriksetmessages: + msg5816
2016-10-28 19:13:37maltesetmessages: + msg5798
2016-10-27 00:02:25jendriksetstatus: chatting -> reviewing
messages: + msg5789
2016-10-21 17:25:21maltesetmessages: + msg5768
2016-10-21 17:20:46jendriksetassignedto: jendrik
2016-10-21 17:20:13jendriksetmessages: + msg5767
2016-10-21 17:10:38maltesetstatus: unread -> chatting
messages: + msg5764
2016-10-21 17:08:45jendrikcreate