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

[Christian Schulte]

Hi Luca,

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.

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?

Anyway, looking forward to getting a LNS contribution for Gecode!

Cheers
Christian

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


-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Luca Di Gaspero
Sent: Saturday, July 06, 2013 9:33 AM
To: users at gecode.org
Subject: [gecode-users] Parameter/Options passing to engines through script

Hi all,

I am trying to re-engineer some piece of code we wrote for enabling Large
Neighborhood Search within Gecode and I am facing the problem (which has
also some general sense) of passing specific parameters (or options objects)
to an engine that has to be managed through the Script<Space>::run<.>()
execution method.

Since I would like to contribute the LNS code to the Gecode community,
before undertaking modifications in my Gecode working copy I would like to
agree it with Gecode maintainers since it will have a (I would say minor)
impact on the framework. 

Other solutions to the problem from more "knowledgeable users" are, of
course, welcome. :-)

Coming to the problem, in detail, the specific option object that is passed
to the run method is dispatched in the Script::run function and a brand new
Search::Option object is sent to the actual engine. Unfortunately this means
that the specific engine could not have access to its specific options and I
found it a general limitation.
Of course it is possible to overcome this limits with workarounds, but they
will somehow break the general framework philosophy.

To be generic enough, my proposal is to add a "Gecode::Options* parameters"
attribute to the Search::Options class in order to allow sending this
specific information to the engine. This variable should be set in the
Script::run(Options, Script) dispatching, e.g., by invoking some
"parameters()" function on the "Gecode::Options& option" object passed to
run.

Just sketching the "pseudo diff" of the tentative modification it will be
something like this:

At search.hh around line 210 add the line
Gecode::Options* parameters;

At script.hpp around line 300 add the line so.parameters = o.parameters();

And, at options.hpp around line 148 add the lines

inline
Options* parameters() {
  return NULL; // for default no specific option is passed to the engine }

This way, the engine has access to parameters and it can cast it to the
opportune parameter class.

Thanks in advance for comments and/or suggestions.

All the best,

Luca
_______________________________________________
Gecode users mailing list
users at gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users