7:35 a.m.
Hi Geoffrey,
I'm
sorry but I have not had time to find a stable solution for
diversification, I must conclude my thesis by April and I have not
much time. For now I solved by calculating a value of penality in the move. But after
graduation I will be happy to try to tackle the problem in a more efficient way :-)
Doing a bit of debugging I noticed that either do not exclude the right moves.
I try to explain better my problem. I have M vehicles and each has its own id (0, M-1). I
have N customer and each of them has its own id (0,N-1). IDs are integer values.
A
move is uniquely identified by a triple of integers: the id of the
customer, the id of the source vehicle and the id of the target vehicle.
(Customer_id, source_route_id, destination_route_id)
when I make this move I would consider taboo all the moves that report the customer in the
source vehicle.
If for example I have 5 vehicles and 20 customer a move could be:
(6,0,1)
so I would avoid all the moves of return, namely:
(6,1,0), (6,2,0), (6,3,0), (6,4,0);
I tried to do as you have suggested me (again if I understood correctly!)
public Collection <? extends Object> getTabuProperties () (
return Arrays. <Integer> asList (customer_id, source_route_id);
)
Only in this way excludes me all the moves that involve the customer and the vehicle
source even if taken separately.
Ex: I esculde also draws (6,1,4) or
(7,0,3)
Thank you from now for all the help you gave me already.
regards,
Marco
8:45 a.m.
New subject: R: [planner] taboo list question
Hi Geoffrey,
Today I tried to follow the process for selecting a tabu move through propertytabuList.
correct me if I misunderstood:
Make a moveCreate a collection of objects through the method getTabuProperties()In the
class AbstractTabuAccepter I check if at least one of these objects is contained in
propertyTabuList. in this case the
move is considered taboo (unless the aspiration criteria). [These
objects are called from the method findTabu(moveScope) of Class
PropertyTabuAccepter]When I chose the move to do for the current step, I insert in
propertyTabuList objects generated by the method getTabuProperties() [these
objects are called from the method findNewTabu(stepScope) of Class
PropertyTabuAccepter]In this way, however, are not able to decide when I make a move which
other moves I considered taboo.
For giving me this opportunity I'm trying a new way.
I
tried to change :
the interface TabuPropertyEnabled adding a method
representationMove()
the method findTabu(moveStep) of Class
PropertyTabuAccepter internally
calls representationMove().In this way the cycle of selecting a move would be:
Make a movecreate a representation of the move with the method representationMove()if this
representation is contained in propertyTabuList the
move is considered taboo (unless the aspiration criterion). [These
objects are called from the method findTabu(moveScope) of Class
PropertyTabuAccepter]When I chose the move to do for the current step, I insert in
propertyTabuList objects generated by the method getTabuProperties() [these
objects are called from the method findNewTabu(stepScope) of Class
PropertyTabuAccepter]
Recalling the example that you had posted yesterday
If for example I have 5 vehicles and 20 customer and I want to move the customer 6 from
the vehicle 0 to vehicle 1, then:
(6,0,1) => is the representation of the move [generated by
representationMove()](6,1,0), (6,2,0), (6,3,0), (6,4,0) => are the moves that I want I
considered taboo. [generated by getTabuProperties()]
By the first tests I noticed that in this way avoids the situation where at an step I make
a move and at the one after a back move. Next week I will have to do some more detailed
tests.
regards,
Marco
5:33 p.m.
New subject: R: [planner] taboo list question
Macro
You're making it way to complicated I think :)
You can probably revert all that fancy stuff and just do:
class MyMove ... {
private A a;
private B b;
private C c;
// I think this is what you need
// It's tabu if the other Move has a AND b
public Collection<? extends Object> getTabuProperties() {
return Collections.<Object>singletonList(
Arrays.<Object>asList(a, b));
}
// my former proposal which isn't what you need apparently
// It's tabu if the other Move has a OR b
public Collection<? extends Object> getTabuProperties() {
return Arrays.<Object>asList(a, b);
}
}
Is "tabu on a AND b" what you need?
If not, add a jira and explain the use case thoroughly and I 'll try to
take a look :)
With kind regards,
Geoffrey De Smet
dmzpippo-drools(a)yahoo.it schreef:
Hi Geoffrey,
Today I tried to follow the process for selecting a tabu move through
propertytabuList. correct me if I misunderstood:
* Make a move
* Create a collection of objects through the method getTabuProperties()
* In the class AbstractTabuAccepter I check if at least one of these
objects is contained in propertyTabuList. in this case the move is
considered taboo (unless the aspiration criteria). [These objects
are called from the method findTabu(moveScope) of Class
PropertyTabuAccepter]
* When I chose the move to do for the current step, I insert in
propertyTabuList objects generated by the method
getTabuProperties() [these objects are called from the method
findNewTabu(stepScope) of Class PropertyTabuAccepter]
In this way, however, are not able to decide when I make a move which
other moves I considered taboo.
For giving me this opportunity I'm trying a new way.
I tried to change :
* the interface TabuPropertyEnabled adding a method
representationMove()
* the method findTabu(moveStep) of Class PropertyTabuAccepter
internally calls representationMove().
In this way the cycle of selecting a move would be:
* Make a move
* create a representation of the move with the method
representationMove()
* if this representation is contained in propertyTabuList the move
is considered taboo (unless the aspiration criterion). [These
objects are called from the method findTabu(moveScope) of Class
PropertyTabuAccepter]
* When I chose the move to do for the current step, I insert in
propertyTabuList objects generated by the method
getTabuProperties() [these objects are called from the method
findNewTabu(stepScope) of Class PropertyTabuAccepter]
Recalling the example that you had posted yesterday
If for example I have 5 vehicles and 20 customer and I want to move the
customer 6 from the vehicle 0 to vehicle 1, then:
* (6,0,1) => is the representation of the move [generated by
representationMove()]
* (6,1,0), (6,2,0), (6,3,0), (6,4,0) => are the moves that I want I
considered taboo. [generated by getTabuProperties()]
By the first tests I noticed that in this way avoids the situation where
at an step I make a move and at the one after a back move. Next week I
will have to do some more detailed tests.
regards,
Marco
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:31 a.m.
New subject: R: [planner] taboo list question
Hi Geoffrey,
I tried to follow your advice, but by debugging I noticed that he still did not consider
taboo the right moves.
For not implementing the changes to the solver I modified the data object model.
But now I have another problem, I do not understand the log.
Normally when I make a move, the undo move is considered taboo for the next X steps i.e.:
-> do a move (CN 16, SR 11) => (CN 16, FR 9)
2010-02-09
15:30:22,700 [main] INFO Step index (29), spend time (32680) taking
steps ((CN 16, SR 11) => (CN 16, FR 9)) out of 1800 accepted moves .
2010-02-09
15:30:22,701 [main] INFO New score
(-65499.76254006752hard/-126.69878682377347soft) is better then last
best score (-76061.73601857488hard/-147.80880935909272soft). Updating best solution and
best score.
-> evaluating next step the undo move (CN 16, SR 9) => (CN 16, FR 11) is considered
taboo
2010-02-09 15:30:22,864 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN 16, FR 11)) is
complete taboo.
2010-02-09
15:30:23,746 [main] INFO Step index (30), spend time (33726) taking
steps ((CN 57, SR 10) => (CN 57, FR 11)) out of 1799 accepted moves .
but often happens that if I make a move the next step make the undo move and then the move
is considered taboo:
-> do a move (CN 28, SR 18) => (CN 28, FR 12)
2010-02-09
15:30:33,344 [main] INFO Step index (39), spend time (43324) taking
steps ((CN 28, SR 18) => (CN 28, FR 12)) out of 1798 accepted moves .
2010-02-09
15:30:33,345 [main] INFO New score
(-44072.81924277624hard/-83.90311931887312soft) is better then last
best score (-44078.036191138206hard/-83.90311931887312soft). Updating best solution and
best score.
-> why evaluating the next step the move (CN 28, SR 12) => (CN 28, SR 18) isn't
considered taboo?
2010-02-09 15:30:33,511 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN 16, FR 11)) is
complete taboo.
44072
2010-02-09 15:30:33,942 [main] DEBUG Proposed move ((CN 57, SR 11) => (CN 57, FR 10))
is complete taboo.
2010-02-09
15:30:34,420 [main] INFO Step index (40), spend time (44400) taking
steps ((CN 28, SR 12) => (CN 28, FR 18)) out of 1798 accepted moves .
2010-02-09
15:30:34,421 [main] INFO New score
(-44078.036191138206hard/-83.90311931887312soft) is not better then
last best score (-44072.81924277624hard/-83.90311931887312soft).
2010-02-09 15:30:34,587 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN 16, FR 11)) is
complete taboo.
2010-02-09 15:30:34,716 [main] DEBUG Proposed move ((CN 28, SR 18) => (CN 28, FR 12))
is complete taboo.
2010-02-09 15:30:35,021 [main] DEBUG Proposed move ((CN 57, SR 11) => (CN 57, FR 10))
is complete taboo.
2010-02-09 15:30:35,487 [main] INFO Step index (41), time spend (45467) taking step (( CN
27 ,SR 10) => ( CN 27 ,FR 12 )) out of 1797 accepted moves.
why this behavior?
regards,
Marco
4:27 a.m.
New subject: R: [planner] taboo list question
Just put a breakpoint in AbstractTabuAccepter and debug your app and you
'll see what actually happens. You 'll probably want to use a
conditional breakpoint, so it only breaks when it's dealing with that move.
Are you using completePropertyTabu?
That shouldn't take a step back to where it came from.
If you're using completeMoveTabu, it can do that, try using
completeUndoMoveTabu instead.
With kind regards,
Geoffrey De Smet
dmzpippo-drools(a)yahoo.it schreef:
Hi Geoffrey,
I tried to follow your advice, but by debugging I noticed that he still
did not consider taboo the right moves.
For not implementing the changes to the solver I modified the data
object model.
But now I have another problem, I do not understand the log.
Normally when I make a move, the undo move is considered taboo for the
next X steps i.e.:
-> do a move (CN 16, SR 11) => (CN 16, FR 9)
2010-02-09 15:30:22,700 [main] INFO Step index (29), spend time (32680)
taking steps ((CN 16, SR 11) => (CN 16, FR 9)) out of 1800 accepted moves .
2010-02-09 15:30:22,701 [main] INFO New score
(-65499.76254006752hard/-126.69878682377347soft) is better then last
best score (-76061.73601857488hard/-147.80880935909272soft). Updating
best solution and best score.
-> evaluating next step the undo move (CN 16, SR 9) => (CN 16, FR 11) is
considered taboo
2010-02-09 15:30:22,864 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN
16, FR 11)) is complete taboo.
2010-02-09 15:30:23,746 [main] INFO Step index (30), spend time (33726)
taking steps ((CN 57, SR 10) => (CN 57, FR 11)) out of 1799 accepted
moves .
but often happens that if I make a move the next step make the undo move
and then the move is considered taboo:
-> do a move (CN 28, SR 18) => (CN 28, FR 12)
2010-02-09 15:30:33,344 [main] INFO Step index (39), spend time (43324)
taking steps ((CN 28, SR 18) => (CN 28, FR 12)) out of 1798 accepted
moves .
2010-02-09 15:30:33,345 [main] INFO New score
(-44072.81924277624hard/-83.90311931887312soft) is better then last best
score (-44078.036191138206hard/-83.90311931887312soft). Updating best
solution and best score.
-> why evaluating the next step the move (CN 28, SR 12) => (CN 28, SR
18) isn't considered taboo?
2010-02-09 15:30:33,511 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN
16, FR 11)) is complete taboo. 44072
2010-02-09 15:30:33,942 [main] DEBUG Proposed move ((CN 57, SR 11) =>
(CN 57, FR 10)) is complete taboo.
2010-02-09 15:30:34,420 [main] INFO Step index (40), spend time (44400)
taking steps ((CN 28, SR 12) => (CN 28, FR 18)) out of 1798 accepted
moves .
2010-02-09 15:30:34,421 [main] INFO New score
(-44078.036191138206hard/-83.90311931887312soft) is not better then last
best score (-44072.81924277624hard/-83.90311931887312soft).
2010-02-09 15:30:34,587 [main] DEBUG Proposed move ((CN 16, SR 9) => (CN
16, FR 11)) is complete taboo.
2010-02-09 15:30:34,716 [main] DEBUG Proposed move ((CN 28, SR 18) =>
(CN 28, FR 12)) is complete taboo.
2010-02-09 15:30:35,021 [main] DEBUG Proposed move ((CN 57, SR 11) =>
(CN 57, FR 10)) is complete taboo.
2010-02-09 15:30:35,487 [main] INFO Step index (41), time spend (45467)
taking step (( CN 27 ,SR 10) => ( CN 27 ,FR 12 )) out of 1797 accepted
moves.
why this behavior?
regards,
Marco
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5202
days inactive
5207
days old
4 comments
2 participants
participants (2)
-
dmzpippo-drools＠yahoo.it -
Geoffrey De Smet