On 15-01-14 21:36, jonathan.labin wrote:
I have a related question and I'd like to ask it by extending the
Say that instead of the solution being one recipe, I am building a
multiple-course meal of recipes.
The problem will define the course slots including the maximum number of
ingredients that can be used and the list of ingredients allowed for the
slots of that course.
Not all courses must have a recipe built. If the constraints of the guests
can be satisfied with fewer courses, the caterer saves money.
Each course is one recipe as described here: a list of ingredients
(in my case i don't particularly care about the order of the ingredients
within the recipe). Certainly each recipe does not need to use it's maximum
number of ingredients.
In my current implementation, I have a flattened list of assignment Planning
Entities where each assignment represents an ingredient slot of a course
For example if the first course has a maximum of 5 ingredients, the second
course has a maximum of 10 ingredients, and the third has a maximum of 3
ingredients, my problem would have a list containing 18 Planning Entities
all in one list.
The trouble with this approach is that each slot is a separate entity. This
means that assigning the ingredient to each of the 5 possible slots of first
course is considered a separate solution when in reality it doesn't matter
which slot of the course the ingredient ends up in. This makes the search
space much larger than it needs to be and results in a lot of swapping of
ingredient assignments within the same course which results in no change in
The curriculum course example had the same problem:
Lectures (= entities) belonging to the same course are interchangeable.
Therefore, I configured the swapMoveSelector as such:
Is there a recommended pattern to model this domain efficiently? Is there a
modification that I can apply to my current representation of this domain
which will allow an ingredient assigned to any slot of a course to be
considered the same?
This cannot (currently) be expressed declaratively on the
We might want to support that in the future (so the filterClass is
automatically applied on the swapMoveSelector etc),
feel free to create a jira.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list