A first version of the task class has been merged. The code is still preliminary 
though, since we want to change the task class interface in multiple directions 
before using it in more parts of the code. I renamed the issue to reflect this. 
Let's close this issue and move the discussion of how to improve the task class 
into the meta issue509.

Once this issue is done tackling issue125 (implementing problem transformations) 
should be much easier.

Yes, I think it would be good if you could have a look at the code. I merged from 
default and the updated pull request is here:
https://bitbucket.org/jendrikseipp/downward/pull-request/17/issue439-task-
class/diff

Results look good. So code review is next, I think?

Can you send me a link for where to do the code review? Staying on bitbucket for
this one is good, I think, but the old link I had doesn't seem to be the correct
one -- e.g. it's showing me conflicts in one of the files. Also, it's been a
while since we touched this, so if this hasn't been done recently we should
probably merge from default before reviewing.

I have run an experiment with a 30 minute timeout and parsed the time it takes to 
initialize the relaxation heuristics (init_time): 
http://ai.cs.unibas.ch/_tmp_files/seipp/issue439-base-issue439-v1-compare-30min.html

Overall, we lose one task, but also solve one additional task. Contrarily to what one 
might expect, the initialization time is even reduced by this change if we look at the 
total or averaged times.

Thanks! I'll have few cycles to attend to this before the proposal deadline. If
you want to make progress in the meantime, I suggest running an experiment that
looks in more detail at the tasks where we lose coverage. I'd be interested in
how far we're seeing a performance decrease and in how far we're seeing random
noise. One suggestion: run each of the tasks where we lose coverage 10 times.

Perhaps an 1800 second time limit might also be interesting.

The current results are not so bad that they absolutely preclude merging, but
they do make me slightly uncomfortable. I thought we shouldn't see much of a
performance deterioriation here because we're only looking at the task class in
the precomputation phase of these heuristics, which ought to be quick.

A first implementation is done. I ran an experiment for ff() and add() with a 
time limit of 5 minutes. The results are here:

http://ai.cs.unibas.ch/_tmp_files/seipp/issue439-base-issue439-v1-compare.html

Excellent, that sounds much like the design we had in mind! Discussing this over
a beer at ICAPS sounds very good. Hopefully, we'll have an exploratory
implementation of the first little bits done by then, which should help make the
discussion more concrete.

It took me a while to find, but it's in a branch called trunk-integration in the 
old downward svn repo.

There's actually not much there, but I think the main trick was creating a class 
called ProblemAdapter, which is the base class everyone who takes a problem 
should use. The idea was to reduce needless duplication of operators (not the 
virtual overheard, like I wrote before), so that if I want to create a problem 
which adds a few operators, I can reuse the operator objects of the original 
problem.
The Problem class inherits from ProblemAdapter, and is used to read the SAS 
description of the problem.

I'd be happy to help with this (or at least, discuss what this should look like 
with you all over a beer at ICAPS).

Hi Erez, that would be useful! Jendrik and I have decided to play around with a
bottom-up approach here: start with something small and only use it in a few
places, then grow it from there.

My hope is that virtual accessor overhead won't matter too much because we don't
refer to the operators etc. directly in the inner loops anyway -- our heuristics
generate their own internal structures for the data that really matters for them.

But for now this is wishful thinking. :-)

I implemented something like this a while ago. While the code has undergone many 
changes, and what I did then is probably not directly usable, maybe some ideas 
from there might be useful.
I seem to recall doing something half-clever to avoid some of the overhead 
associated with virtual accessors for operators. I'm pretty sure it's in some 
branch somewhere - I can dig it up if you're interested.

As discussed previously, we would like to add a "PlanningTask" class that 
encapsulates variables, operators, etc.