Re: [rules-users] [Optaplanner] Filter values = immovable planning entities
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 SolutionHardSoftScore {
private ListPerson persons;
private ListDesk desks;
private HardSoftScore score;
@PlanningEntityCollectionProperty
public ListPerson getPersons() {
return persons;
}
public void setPersons(ListPerson persons) {
this.persons = persons;
}
public void setDesks(ListDesk desks) {
this.desks = desks;
}
@ValueRangeProvider(id=deskRange)
public ListDesk 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 SelectionFilterPerson 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
Re: [rules-users] [Optaplanner] Filter values = immovable planning entities
On 12-12-13 18:11, Mats Norn 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
Re: [rules-users] [Optaplanner] Filter values = immovable planning entities
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 SolutionHardSoftScore {
private ListPerson persons;
private ListDesk desks;
private HardSoftScore score;
@PlanningEntityCollectionProperty
public ListPerson getPersons() {
return persons;
}
public void setPersons(ListPerson persons) {
this.persons = persons;
}
public void setDesks(ListDesk desks) {
this.desks = desks;
}
@ValueRangeProvider(id=deskRange)
public ListDesk 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.
Does the SelectionFilter prevent the desk being assigned somehow? I
thought a SelectionFilterPerson 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.comwrote:
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
listrules-users@lists.jboss.orghttps://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
Re: [rules-users] [Optaplanner] Filter values = immovable planning entities
On 13-12-13 10:39, Mats Norn 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
SolutionHardSoftScore {
private ListPerson
persons;
private ListDesk
desks;
private HardSoftScore score;
@PlanningEntityCollectionProperty
public ListPerson
getPersons() {
return persons;
}
public void
setPersons(ListPerson persons) {
this.persons = persons;
}
public void
setDesks(ListDesk desks) {
this.desks = desks;
}
@ValueRangeProvider(id="deskRange")
public ListDesk
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
SelectionFilterPerson 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 Norn 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 :)
