Thanks!
It turns out that it was bad data in my factory to create the initial solution
that made some of
On Fri, Dec 13, 2013 at 11:51 AM, Geoffrey De Smet <ge0ffrey.s...@gmail.com>
wrote:
>
> On 13-12-13 10:39, Mats Norén wrote:
>> Bad choice of words. Entities. :-)
>>
>> I've got three classes:
>>
>> @PlanningEntity(movableEntitySelectionFilter =
>> MovableWorkersSelectionFilter.class)
>> public class Person extends Property {
>>
>> String signature;
>> String name;
>> Desk desk;
>> boolean movable;
>> ...
>> }
>>
>> Fact:
>>
>> public class Desk extends Property {
>>
>> double x;
>> double y;
>>
>> public Desk() {
>> }
>> ...
>> }
>>
>> Solution:
>>
>> @PlanningSolution
>> public class DeskAssignmentSolution implements Solution<HardSoftScore> {
>>
>> private List<Person> persons;
>> private List<Desk> desks;
>> private HardSoftScore score;
>>
>> @PlanningEntityCollectionProperty
>> public List<Person> getPersons() {
>> return persons;
>> }
>>
>> public void setPersons(List<Person> persons) {
>> this.persons = persons;
>> }
>>
>> public void setDesks(List<Desk> desks) {
>> this.desks = desks;
>> }
>>
>> @ValueRangeProvider(id="deskRange")
>> public List<Desk> getDesks() {
>> return desks;
>> }
>> ...
>>
>> }
>>
>> A desk is assigned to a person and makes up a desk assignment solution.
>>
>> Certain desks should not be assigned since the are all ready occupied. The
>> are correctly assigned to the right person in the initial solution.
> Ah.
> So there are 2 requirements:
> - Some persons are immovable: they are already assigned to a desk
> (MovableWorkersSelectionFilter somehow recognizes those and filters them
> out).
> - Since no 2 persons can share the same desk, there's little point in putting
> a desk that is already assigned to an immovable person in the value range.
> You can filter them out of the value range (by putting filters in the CH and
> local search etc), but I wouldn't bother with that improvement: your original
> hard constraint "no 2 persons can share the same desk" will gives those moves
> an infeasible score, so they are unlikely to be picked anyway (and if they
> are picked it can actually be a good thing: tunnel through an infeasible
> solution to a better feasible solution).
>
>>
>> Does the SelectionFilter prevent the desk being assigned somehow? I thought
>> a SelectionFilter<Person> would only prevent a move of the Person but it's
>> the Desk being assigned?
>>
>> Regards,
>> Mats
>>
>>
>> On Fri, Dec 13, 2013 at 9:32 AM, Geoffrey De Smet <ge0ffrey.s...@gmail.com>
>> wrote:
>>>
>>> On 12-12-13 18:11, Mats Norén wrote:
>>>> Hi,
>>>> I've got a domain with the following entities:
>>> entities? you mean classes?
>>>> - Person (planning entity)
>>>> - Desk (planning variable)
>>> a class cannot be a variable. This probably a problem fact that and
>>> person.getDesk() nor DeskAssignement.getPerson() is the planning variables.
>>>> - DeskAssignment (solution)
>>> Now I am totally confused :)
>>> in the official examples, something called Assignment is a planning entity.
>>>>
>>>> All persons should be assigned to a desk according to some rules.
>>>> What I would like to do is to make certain Persons and their Desk
>>>> immovable, ie, they are assigned a desk in the initial solution and should
>>>> be fixed there. They are only there for the score calculation.
>>> agreed, "immovable" is the correct concept to use for that
>>>>
>>>> I looked at 14.3.1 Immovable planning entities but couldn't really see how
>>>> I would apply it to my use case.
>>> Take a look at the course scheduling example.
>>> Here's a demo of immovable planning entities in that example:
>>> http://www.youtube.com/watch?v=4meWIhPRVn8
>>>> Why is the filter applied at the planning entity level? Since it's the
>>>> planning variable that changes I thought that I should somehow filter the
>>>> allowed values for the Desk.
>>> Don't mix the concept of "(im)movable entities" (which is what you want)
>>> with the concept of "limiting value ranges per entity" or the concept of
>>> "filtering specific move selectors" (which is overkill and convoluted for
>>> your needs).
>>>>
>>>> Regards,
>>>> Mats
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
