Hi Felix,
I think your special branchers could be implemented quite easily by
instantiating the existing branchers with new views. The views would store the
interval you're interested in and reimplement the assigned() function, so that
it returns true if the domain does not intersect the given interval. That way,
the brancher will ignore all views that are assigned in this sense.
You will still have to duplicate some code, but half of it is generated anyway.
Have a look at post-view-int.bs, which is used to generate post-view-int.cpp.
I think you would only need to replace IntView by your "IgnoreIntervalView".
Then duplicate post-val-int.hpp, where you'll also have to replace the views
accordingly (you will need something like a "MinusIgnoreIntervalView").
Cheers,
Guido
Felix Brandt wrote:
> Hi,
>
> for a recent project I wrote a custom brancher (similar to the
> ViewBrancher) that only branches variables within a certain interval.
> The variables, which do not intersect the interval, are considered as if
> they are already assigned.
>
> In my case I wasn't interested in the values if they did not match the
> given interval, but also did not want to add auxiliary variables and
> constraints to be able to use standard branchers. Furthermore, I could
> not just assign border values without breaking constraints. I assume
> that such a brancher can also be advantageous in other setups, where one
> wants to apply varying branching strategies to different parts of the
> variable domains.
>
> If this idea is of interest for the project, I could try to extend the
> current ViewValueBrancher. Right now, I'm not sure where to start.
> Probably adapting ViewBrancher<ViewSel>::status(const Space&) is a good
> starting point, but it's quite deep in the object hierarchy so I assume
> it's not *that* easy. Additionally, inheriting from ViewBrancher seems
> to produce a lot of duplicated code (for brancher assembly and strategy
> selection). Any suggestions?
>
> Regards,
> Felix
>
> PS: If I miss something obvious or this feature is already present, I
> would appreciate any hint :-)
>
>
> _______________________________________________
> Gecode users mailing list
> [email protected]
> https://www.gecode.org/mailman/listinfo/gecode-users
--
Guido Tack, http://people.cs.kuleuven.be/~guido.tack/
_______________________________________________
Gecode users mailing list
[email protected]
https://www.gecode.org/mailman/listinfo/gecode-users
