Author malte
Recipients andrew.coles, erez, florian, jendrik, malte, silvia
Date 2016-12-14.18:28:50
> Regarding the first item: bjolp uses uniform cost partitioning, so CPLEX is not
> involved. Probably you meant seq instead of bjolp. I suggest to rerun the
> experiment for seq once we've merged the new hash table implementation.

Yes, I meant seq. Regarding rerunning the experiments, does this mean that you
advocate against testing the new hash table implementation on our standard
optimal planning configurations? Since it's a rather performance-critical
change, I'd be happier to have it evaluated on more than just blind search
before merging. (But perhaps this discussion should be in issue694.)

> Regarding the second item: I think it would be good to defer experiments until
> we're happy with optimal configurations.

Fine with me. I don't think we need to test the satisficing configurations for
issue692, but I think we should for issue693 (some domains have massively larger
states, so hash function performance could be interesting) and for issue694 (for
similar reasons). But of course we can focus on optimal configurations for these
issues first.

> We could convert the lazy open list 
> operator pointers in issue688. Or do you prefer a separate issue for that?

Separate issues are usually easier to review and hence faster to be merged. This
is especially true when we expect a performance impact from some of the changes
and want to know where it comes from. So I think in this case a separate issue
would be better.
Date User Action Args
2016-12-14 18:28:50maltesetmessageid: <>
2016-12-14 18:28:50maltesetrecipients: + malte, erez, andrew.coles, silvia, jendrik, florian
2016-12-14 18:28:50maltelinkissue213 messages
2016-12-14 18:28:50maltecreate