9 a.m.
Hello,
I'm having a problem to plan my solver, I'm wondering if it's possible to
configure the solver, so that it picks the best solution from multiple
collections of planning variables. Here is an example, to be more precise:
I have 3 planning variables: X, Y, Z. and many collections of values of
these variables. For example, collection A contains three X values, five Y
values, and two Z values; other collection would contain different values
etc. And the problem is that the values from different collections can't be
mixed with each other, and I don't know how to prevent that.
I have tried different approaches but with no luck... Tried to mix all of
the values together identifying them with a collection ID, and setting in
rules a negative score for the ones that are not from the same collection,
but its very inefficient, and the solver never stops (despite the fact that
the timeout was set for 120sec).
I was thinking about using multiple @PlanningEntities, but as far as I know
it is not supported, so I have resigned from this idea.
I have also tried using @ValueRange type FROM_PLANNING_ENTITY_PROPERTY, and
in MoveFactory I have changed planningEntityProperty according to the
collection I was using, but it led to exception "Corrupted Undo Move", and
all in all I think it was a bad idea.
My last idea, which I have not tested yet, is to make two different solvers,
one would find best solution for the given collection, and from all of the
best solutions from these collections, the next solver would pick the best
one, but I think this might be a very inefficient way of doing it.
I'm really sorry if I made this post very hard to understand, but my problem
is a bit more complicated then it sound, and its hard to describe it :P I
would appreciate any tips/ideas how I could configure/plan my solver, and
rules so it would work better.
Thanks in advance,
Mateusz
--
View this message in context:
http://drools.46999.n3.nabble.com/Planner-Planning-problem-looking-for-ti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10:40 a.m.
On 09-05-13 16:00, Mz wrote:
Hello,
I'm having a problem to plan my solver, I'm wondering if it's possible to
configure the solver, so that it picks the best solution from multiple
collections of planning variables. Here is an example, to be more precise:
Interesting use case. Are you free to explain the practical appliance a
bit more so we can understand it better?
I have 3 planning variables: X, Y, Z. and many collections of values of
these variables. For example, collection A contains three X values, five Y
values, and two Z values; other collection would contain different values
etc. And the problem is that the values from different collections can't be
mixed with each other, and I don't know how to prevent that.
A) One approach
would be to use a custom move factory/iterator that
generates moves
which move all 3 variables to any value for which the 3 values stem from
the same collection.
If you only use that move selector, you wouldn't even need to check that
the variables use the same collection with a constraint (as it would be
build-in).
I have tried different approaches but with no luck... Tried to mix all of
the values together identifying them with a collection ID, and setting in
rules a negative score for the ones that are not from the same collection,
but its very inefficient,
B) Normally, I 'd recommend this approach, but indeed
it will be very
inefficient.
The metaheuristics would be continually score trapped (see latest docs
on "score trap"), making it unlikely that they switch collection.
Mixing in custom moves (like the one from approach A) with normal moves
would make this approach viable too.
C) A drastic, but simpler approach, if those collections are always
small (otherwise it will run into scaling issues), is the following:
Use a single variable. Create a cross product of all 3 values in each of
the collections and use such a combination as the value.
For example, collection A results into 3 * 5 * 2 = 15 combinations. Add
the results of combinations of the other collections and that's the
range for that single variable.
and the solver never stops (despite the fact that
the timeout was set for 120sec).
That sounds like a bug. Older versions had this
problem, but recent ones
don't (I don't recall for which version it was fixed).
Enable trace logging and see what the logging says.
I was thinking about using multiple @PlanningEntities, but as far as I know
it is not supported, so I have resigned from this idea.
I don't see how
multiple @PlanningEntities would fix it.
Support for multiple @PlanningEntities is getting better since
6.0.0.Beta1, but not perfect yet.
I have also tried using @ValueRange type FROM_PLANNING_ENTITY_PROPERTY, and
in MoveFactory I have changed planningEntityProperty according to the
collection I was using, but it led to exception "Corrupted Undo Move", and
all in all I think it was a bad idea.
FROM_PLANNING_ENTITY_PROPERTY had a
regression in 5.5, but works well
again since 6.0.0.Beta1
My last idea, which I have not tested yet, is to make two different solvers,
one would find best solution for the given collection, and from all of the
best solutions from these collections, the next solver would pick the best
one, but I think this might be a very inefficient way of doing it.
This is
basically partitioning, which is a suboptimal approach. I
wouldn't recommend it.
I'm really sorry if I made this post very hard to understand, but my problem
is a bit more complicated then it sound, and its hard to describe it :P I
would appreciate any tips/ideas how I could configure/plan my solver, and
rules so it would work better.
Thanks in advance,
Mateusz
--
View this message in context:
http://drools.46999.n3.nabble.com/Planner-Planning-problem-looking-for-ti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:40 a.m.
Thank you for your replay!
I think I can explain briefly its practical usage. This collections, I
mentioned before, are providers who offer different "goods" with
configurable parameters (our planning variables). Clients can order "goods"
with specific parameters (parameters specified by client, can be range of
values for example: from 1 to 10; or array of values: 1,2,3), we check if
any of our providers are able to create what our client ordered, and pick
the best solution (based on price, and parameters).
If our project will open its source I might talk about it in more detail
later, and link it here.
I will try approach A, currently I'm using custom move factory, but I always
thought that every single planning variable must have its own move
factory... my bad. Also this approach looks fairly easy to implement, and
maybe I will switch to version 6.0.0.Beta1. I will give you an update next
week if I had any luck with it.
ge0ffrey wrote
> and the solver never stops (despite the fact that
> the timeout was set for 120sec).
That sounds like a bug. Older versions had this problem, but recent ones
don't (I don't recall for which version it was fixed).
Enable trace logging and see what the logging says.
Actually it was enabled, but there was no errors, solver just kept on
moving, and in logs all I could find was "move score (...) for move: (...)"
and the logs from rules I made...
On the other hand when I removed my rule which checked if variables was from
the same provider, solver as expected timeout after 120sec and returned
actual best solution. This rule had a lot of compare operations etc, so that
might have been the cause in someway.
ge0ffrey wrote
> I was thinking about using multiple @PlanningEntities, but as far
as I
> know
> it is not supported, so I have resigned from this idea.
I don't see how multiple @PlanningEntities would fix it.
Support for multiple @PlanningEntities is getting better since
6.0.0.Beta1, but not perfect yet.
I thought that multiple @PlanningEntities might have help, if I would use
one of the @PlanningEntities to find best offered "Good" from each of the
providers, then other @PlanningEntity would pick the best "good" from the
"goods" found earlier. But it was just one of the ideas I was thinking
about.
Thank you for your advices again,
Mateusz
--
View this message in context:
http://drools.46999.n3.nabble.com/Planner-Planning-problem-looking-for-ti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3:46 a.m.
On 10-05-13 15:40, Mz wrote:
I think I can explain briefly its practical usage. This collections,
I
mentioned before, are providers who offer different "goods" with
configurable parameters (our planning variables). Clients can order "goods"
with specific parameters (parameters specified by client, can be range of
values for example: from 1 to 10; or array of values: 1,2,3), we check if
any of our providers are able to create what our client ordered, and pick
the best solution (based on price, and parameters).
If our project will open its source I might talk about it in more detail
later, and link it here.
Sounds like an interesting use case indeed :)
4034
days inactive
4038
days old
3 comments
2 participants
participants (2)
-
Geoffrey De Smet -
Mz