2011/10/19 Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
**
Op 19-10-11 15:00, Guilherme Kunigami schreef:
> In this use case, that is probably a bad idea in my experience. Why? Well
> I hope this makes any sense:
> *You need to allow the optimization algorithms to break it now and then
> to tunnel through a bad search space into another good search space.*
> If it doesn't, don't worry.
>
Hmm, I think I understood it. Allowing infeasible solutions may help to
scape from local minima in the space of feasible solutions for example.
Yep :)
rule "Avoid conflicting activities"
> when
> Assignment($room1 : room, $act1: activity, $id : activity.id)
> Assignment(room== $room1, room != null, $act2 : activity, activity.id >
> $id)
> Conflict(act1 == $act1, act2 == $act2)
>
> I would put Conflict first. But try it this way too and let me know which
> works better ;) I don't know.
> Stated differently: Instead of checking every 2 simultaneous assignments
> if they are a conflict,
> I would check if every 2 conflict assignments are simultaneous (like in
> examinationScoreRules.drl).
>
>
Ok! I will perform some stress tests to verify which one works better.
Nice, please report your results to this mailing list. It doesn't matter if
they are worse, better or equal: it's interesting to know.
Look for "stepLimit" in the examples to see how I do very short stress
tests when adding extra constraints.
I've made a test with each model limited to 70 steps. I've attached a
graph
comparing both runs using drools planner benchmark.
It seems that using Conflict first is indeed faster :)
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users