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.digasp...@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 _______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
