Hi Christian,
Thanks for your reply again!
I am reluctant to use Gecode features that are not in the official
releases yet, as the user should be able to compile ECLiPSe and its
open-source third-party components (like Gecode) on their own.
Currently, the released gfd interface is to Gecode 3.7. I have not
updated the release to Gecode 4(.2) mainly because I do not want to
remove the RESTART search engine, only to reintroduce the equivalent
when I get RBS working with gfd.
I understand that it is easiest and perhaps best to use a common base
type for the search engines, but in the absence of this base type at the
moment, should I try to hide the different types of search engines
inside my GecodeSearch class? Currently I have a singe Engine* (sengine)
that points to the actual search engine, and a next method to obtain the
next solution but I assume I can have different (private) pointers to
the different search engines, and a next method that calls the
appropriate next, depending on the search method.
I also have a related question about getting the next solution with RBS
-- I had assumed that the next solution will be computed with a restart,
but as there seems to be 2 search engines in rbs, with RBS controlling
the restart on another engine doing the "actual" search (e.g. BAB), I am
wondering if the behaviour when getting the next solution is controlled
by this "actual" search engine, and for BAB, I don't think this is done
with a restart (hence the need for the old RESTART engine). So is the
search restarted when next() is called in RBS, or does this depend on
the "actual" search engine?
Assuming that the search is restarted with next(), then can the
functionality of the old RESTART engine be reproduced by setting the
cutoff threshold to be very high? A related question is if it make sense
(and if so, is there any way to do so) to use something other than the
number of failures for deciding when to restart?
Cheers,
Kish
On 22/08/2013 08:49, Christian Schulte wrote:
Hi Kish,
My bad... There is really no common basetype for search engines, the type I
mentioned is actually for the implementations and not the interfaces...
I think you will have to wait until I have added a common basetype (there is
a basetype, but it is not powerful enough), I might be able to do it until
the end of the week.
Sorry for the confusion!
Cheers
Christian
--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/
-----Original Message-----
From: Kish Shen [mailto:kiss...@cisco.com]
Sent: Thursday, August 22, 2013 9:45 AM
To: cschu...@kth.se
Cc: users@gecode.org
Subject: Re: [gecode-users] Adding restart-based search to ECLiPSe's
interface to Gecode
Hi Christian,
Thanks again!
On 21/08/2013 19:17, Christian Schulte wrote:
Try to avoid the Gecode::Search::bab .... functions. Just create as
follows:
Gecode::Search::Engine* e = new Gecode::BAB(...) Then it also will
work for RBS, and you do not have to create a second engine yourself,
this will the RBS class do for you.
And do not forget to delete e eventually!
This is the part that I don't know how to do correct -- probably because of
my lack of C++ knowledge, but as far as I can tell, Gecode::DFS etc are not
of class Engine*, according to the doc:
template<class T>
class Gecode::DFS<T>
for subclasses T of Space
T is GecodeSpace in my case, I assume. I am not sure what class DFS is, but
I can't see how it could be Engine*.
Anway, I tried to do the assignment as you suggested:
Search::Engine* segine;
...
sengine = new DFS<GecodeSpace>(solver, o); and indeed I get the error
cannot convert 'Gecode::DFS<GecodeSpace>*' to 'Gecode::Search::Engine*'
(I first tried sengine = new DFS(solver, o) but got an error 'expected
type-specifier')
So I am not sure what to do -- do I need to change the type of sengine,
and/or the way I assign an engine to sengine?
Cheers,
Kish
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
