OK, let's close this for now. We really need a way to do automated performance
regression testing...

We don't, but there have been many changes since then (mostly translator).
However, I tested on some of the detailed results from satellite, and I get
number that are more or less in the correct proportion to the results in
your paper.

On Mon, Mar 8, 2010 at 2:27 PM, Malte Helmert <
downward.issues@googlemail.com> wrote:

>
> Malte Helmert <helmert@informatik.uni-freiburg.de> added the comment:
>
> Can you test that we now get the results in the paper by Silvia and me?
>
> _______________________________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://alfons.informatik.uni-freiburg.de:8088/downward-issues/issue79>
> _______________________________________________________________________
>

-- 

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

Can you test that we now get the results in the paper by Silvia and me?

I fixed it in r4052.
It was a stupid logic bug in the creation of the open list.

OK, this needs investigating. I'd suggest not to use the eager search algorithm
for any experiments until this is resolved. (I guess this includes A*.)

kf and kfF perform the same (also ky and kyY) on a few problems I've tested.
However, kfy is different than kfyFY.
It might be the case that the heuristic decrease enough so that the
preferred operators don't matter,
although I think this is unlikely.

Erez.

On Sun, Mar 7, 2010 at 6:19 PM, Malte Helmert <
downward.issues@googlemail.com> wrote:

>
> Malte Helmert <helmert@informatik.uni-freiburg.de> added the comment:
>
> Not sure if I understand that correctly, but if a configuration that does
> not
> use pref. ops. performs the same as one that does (with the same
> heuristic),
> that is very much not correct. :-)
>
> Pref. ops. should give a huge increase of performance. Can you explain your
> last
> two sentences in more detail? Which precise command-line parameters do you
> use
> in the two cases?
>
> _______________________________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://alfons.informatik.uni-freiburg.de:8088/downward-issues/issue79>
> _______________________________________________________________________
>

-- 

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

Not sure if I understand that correctly, but if a configuration that does not
use pref. ops. performs the same as one that does (with the same heuristic),
that is very much not correct. :-)

Pref. ops. should give a huge increase of performance. Can you explain your last
two sentences in more detail? Which precise command-line parameters do you use
in the two cases?

Changed in r4051
Note that I added another vector for estimate_heuristics.
Also - I noticed that with eager search and one heuristic, using preferred
operator of the same heuristic that is used for estimates does not change the
search at all. I'm not sure if this is correct or not.

Gabi Röger wrote:
> On 03/05/2010 10:42 PM, Malte Helmert wrote:
>> Karpas Erez wrote:
>>
>>>> One question though about the change to
>>>> eager_greedy_best_first_search.cc in r4013. It looks like before the
>>>> change, heuristics were only added to the alternation queue if they were
>>>> in "heuristics". Now they're added if they are in "heuristics" or in
>>>> "preferred_operator_heuristics". Is this the correct behaviour? (CCing
>>>> Gabi because she implemented the open lists.)
>>>>
>>> This is the same as in the lazy search. However, thinking about it now, the
>>> usage is a bit different, so I think you're right.
> 
> I think this is correct. If the preferred operators of a heuristic
> are used, then there is an additional queue for these operators, but
> there is still the normal queue for this heuristic that includes all
> successors. Malte, is this not as it was done in the original
> implementation?

Erez: Gabi and I discussed this in person and agreed that the intention
is to only add to the alternation queue only those heuristics for which
"use_estimates" is set. So this should be changed in both eager and lazy
search.

CC'ing the tracker so that a bug report is automatically created from
this. Let's see if that works. :-)

Cheers,

Malte