2011/10/19 Geoffrey De Smet <[email protected]> > ** > > > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > >
<<attachment: solution2Statistic.png>>
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
