[gecode-users] Parameter/Options passing to engines through script

[Christian Schulte]

Hi Luca,

Sorry for the delay but I did not really know what to answer ;-)

What would help me here is to understand the design of your LNS engine and
only then think how it could be best integrated into the Gecode jungle...
So, maybe you could summarize:
 - what does the engine do
 - what does it require from a space (you already mentioned two additional
member functions)
 - what other parameters are needed to control the engine

Could you do that?

Cheers
Christian

--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/


-----Original Message-----
From: Luca Di Gaspero [mailto:l.digaspero at uniud.it] 
Sent: Monday, July 08, 2013 7:38 PM
To: cschulte at kth.se
Cc: Tommaso Urli; users at gecode.org
Subject: Re: [gecode-users] Parameter/Options passing to engines through
script


Hi Christian,

> I think this is not a good idea: this would make the use of LNS depend 
> on the fact that one uses a Script-derived class.

> But this is not general enough, as Script is just a convenience class 
> for the commandline driver. In order to be fully general it also 
> should work for any subclass of Space.

Actually the LNS engine is currently only moderately dependent on Space: it
will ask for a decorated Space implementing two additional methods Space*
relax() and void relaxable_var in a similar way as the master() and slave()
methods for restarts. We also provide some standard convenience template
decorator class which takes a generic Space and require the redefinition of
those specific methods by multiple inheritance in a neat way.

> Did you think about extending the Search::Options class with what you 
> need and then add the appropriate commandline options to control the 
> parameters in the search options? Maybe you just tell us what options you
need?

We actually did it for the non-scriptable variant of the meta-engine. That
is the LNS<template<class> class E, class T>(T*, Search::Options& o) is
meant to be used with a specific subclass of Search::Options, called
LNSOptions, which inherits from InstanceOptions and augments it with
LNS-specific parameters. This has been done by
dynamic_cast<LNSOptions*>(&o)-ing (and checking whether the correct class
has been provided).

However, the problem we are currently facing is that we would like to use
that meta-engine also with the Script<Space>::run static method (because it
is integrated in a specific GUI and we want to reuse it as much as we can),
but the LNSOptions class will be not sent through it to the end-level engine
(as it will be dispatched and some of the (standard) options coming, e.g.,
from the command-line driver, are copied in a fresh Search::Option object
(around line 300 in script.hpp) that is provided to the (meta-)engine.

Moreover, apart of the LNS specific parameters, the possibility to marshall
customized parameters directly to the engine from the command-line will ease
the development of engines by different contributors: of course I can list
the parameters we need for LNS, but I had also in mind to contribute further
hybrid solvers for which different parameters should be provided, therefore
I was looking to some more flexible way to achieve this goal.

So, I would like to agree with you some parameter passing mechanism that
could be general enough for this purpose. Once this issue is solved, Tommaso
Urli (the coauthor of this engine) and myself will be very happy to
contribute the LNS code :-) [apart of jokes, if you would like to access the
current version of the engine for searching a solution to the problem, I
will send you the source code].

Thanks and all the best,

Luca


--
Luca Di Gaspero, PhD http://www.diegm.uniud.it/digaspero/
DIEGM, Università di Udine 	email: luca.digaspero at uniud.it
via delle Scienze, 208 		tel: +39-0432-558242
33100 Udine, ITALY 			fax: +39-0432-558251
-
PGP Key ID 1EE94BEA registered at http://pgpkeys.mit.edu