To regenerate them for every step, extend AbstractMoveFactory directly,
instead of CachedMoveFactory.
isMoveDoable() should only be used if it corrupts the solution.
Generally, it's not a good idea to use it to check hard-constraints
(even build-in hard-constraints).
Check the manual for the difference on "build-in hard constraints" and
(normal, real) "hard constraints".
The accepted move size is the number of moves that are accepted, not the
number that is selected.
This is the work flow:
- x moves get selected. The MoveFactory
- a non doable move gets ignored. y moves are doable
- the move's score is calculated
- the move is accepted or not. z moves are accepted
- the best move is selected as a step. With mininimalAcceptedSelection,
z is limited.
Op 13-07-12 17:54, Garf schreef:
my error here in looking to extend CachedMoveFactory. Obviously, the
moves
are cached, and not regenerated each forage.
I suppose if I wanted to achieved what I wanted, I'd just override
isMoveDoable() to make it more discerning -- but,as the JavaDoc suggests,
there's little benefit to doing this. I'd be putting business logic into
Java that would be redundant to the rules, with little performance gains.
--
View this message in context:
http://drools.46999.n3.nabble.com/Planner-5-4-Overriding-CachedMoveFactor...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
With kind regards,
Geoffrey De Smet