2:35 a.m.
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Beta1
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection are fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes to long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:37 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3317:
--------------------------------------
Description:
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
was:
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection are fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes to long.
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Beta1
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:15 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3317:
--------------------------------------
Fix Version/s: 5.4.0.Beta2
(was: 5.4.0.Beta1)
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Beta2
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:25 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3317:
--------------------------------------
Fix Version/s: 5.4.0.Beta3
(was: 5.4.0.Beta2)
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Beta3
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:08 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Chris Dolan commented on JBRULES-3317:
--------------------------------------
Could someone please add a brief note about this in the docs? I think the workaround is
quite acceptable, but the docs are very misleading because they say "If null is a
valid planning value, it should be included in the value range and the default way to
detect uninitialized planning variables must be changed."
(http://docs.jboss.org/drools/release/5.4.0.Beta2/drools-planner-docs/html...)
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.CR1
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:53 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3317:
-------------------------------------------
@Chris note added in the docs for 5.4.0.CR1, thanks for reporting
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.CR1
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:36 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Toni Rikkola updated JBRULES-3317:
----------------------------------
Fix Version/s: 5.4.0.Final
(was: 5.4.0.CR1)
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Final
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:55 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3317:
--------------------------------------
Fix Version/s: (was: 5.4.0.Final)
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:10 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3317:
-------------------------------------------
Annotations and stuff:
@PlanningVariable gets nullable : boolean
@PlanningVariable gets uninitializedSelectionFilter : SelectionFilter
Effects of having a nullable planning variable:
Local Search moves can put a planning variable back to null
Pretty straightforward, just add null to the planning value range
Construction heuristics (CH)
CH only fills in all vars, unless the uninitializedSelectorFilter filters them
out.
non-nullable var
uninitializedSelectorFilter defaults to var == null
nullable var
unintializedSelectoFilter defaults to nothing
everything is considered uninitialized
If CH choses to fill it in with null, that’s fine.
CH needs to make sure it fills in each vars no more than once
When to apply the uninitialized filter in CH?
Example: a solution will be "good enough" when only one of the two
trains reaches its destination. in this case, once I have one train reaching the
destination, I can safely assume the other to be Nullable.
By using no higher than cacheType STEP the filter will be called at every
step
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:33 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3317:
-------------------------------------------
After this is fixed, I need to look at excludeUninitializedPlanningEntity, which should
use the filter system and be compatible.
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:21 a.m.
[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3317:
-------------------------------------------
Done:
- domain stuff etc
- Local search
- docs
Todo:
- Construction heuristics (requires the new selector architecture)
- Clearly define strict and non-strict initialized => Define that
SolutionDescriptor.isInitialized is non-strict and ignores uninitializedEntityFilter
- Rewrite excludeUninitializedPlanningEntity
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL: https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4390
days inactive
4674
days old
10 comments
5 participants
participants (5)
-
Chris Dolan (JIRA) -
Geoffrey De Smet (Created) (JIRA)
-
Geoffrey De Smet (JIRA)
-
Geoffrey De Smet (Updated) (JIRA)
-
Toni Rikkola (JIRA)