Title preliminary task class implementation
Priority feature Status resolved
Superseder Nosy List erez, haz, jendrik, malte, mkatz
Assigned To jendrik Keywords
Optional summary

Created on 2014-06-06.14:38:29 by jendrik, last changed by mkatz.

msg4013 (view) Author: jendrik Date: 2015-02-19.14:48:39
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.
msg3915 (view) Author: jendrik Date: 2014-12-12.15:01:35
Once this issue is done tackling issue125 (implementing problem transformations) 
should be much easier.
msg3660 (view) Author: jendrik Date: 2014-10-05.22:19:21
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:
msg3616 (view) Author: malte Date: 2014-10-03.23:52:39
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.
msg3608 (view) Author: jendrik Date: 2014-10-02.12:22:24
I have run an experiment with a 30 minute timeout and parsed the time it takes to 
initialize the relaxation heuristics (init_time):

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.
msg3551 (view) Author: malte Date: 2014-09-26.14:11:04
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.
msg3550 (view) Author: jendrik Date: 2014-09-26.09:31:42
A first implementation is done. I ran an experiment for ff() and add() with a 
time limit of 5 minutes. The results are here:
msg3198 (view) Author: malte Date: 2014-06-06.16:58:52
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.
msg3197 (view) Author: erez Date: 2014-06-06.16:53:40
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 
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).
msg3196 (view) Author: malte Date: 2014-06-06.15:15:13
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. :-)
msg3195 (view) Author: erez Date: 2014-06-06.14:46:14
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.
msg3194 (view) Author: jendrik Date: 2014-06-06.14:38:29
As discussed previously, we would like to add a "PlanningTask" class that 
encapsulates variables, operators, etc.
Date User Action Args
2015-04-20 09:35:25mkatzsetnosy: + mkatz
2015-02-19 14:48:39jendriksetstatus: reviewing -> resolved
messages: + msg4013
title: task class -> preliminary task class implementation
2014-12-12 15:01:35jendriksetmessages: + msg3915
2014-10-05 22:19:21jendriksetstatus: chatting -> reviewing
messages: + msg3660
2014-10-03 23:52:39maltesetmessages: + msg3616
2014-10-02 12:22:24jendriksetmessages: + msg3608
2014-09-26 14:11:04maltesetmessages: + msg3551
2014-09-26 09:31:42jendriksetmessages: + msg3550
2014-08-29 13:22:45hazsetnosy: + haz
2014-06-06 16:58:52maltesetmessages: + msg3198
2014-06-06 16:53:40erezsetmessages: + msg3197
2014-06-06 15:15:14maltesetmessages: + msg3196
2014-06-06 14:46:14erezsetstatus: unread -> chatting
nosy: + erez
messages: + msg3195
2014-06-06 14:38:29jendrikcreate