Have you considered this alternative model?
class VehicleType{} // PickupTruck, TractorTrailer, ...
class Vehicle { // For example the PickupTruck with license plate 123
VehicleType vehicleType;
String licensePlate;
}
class or enum FurnitureType{} // SmallChair, LargeSofa, ...
class Furniture {
FurnitureType furnitureType;
String serialNumber;
}
@PlanningEntity
class Assignment {
Furniture furniture;
@PlanningVariable Vehicle vehicle;
}
then you also need a way to define your configs:
class ValidConfig { // For example PickupTruck can have 1xLargeSofa and
3xSmallChair
VehicleType vehicleType;
Map<FurnitureType, Integer> furnitureTypeCounts;
}
// Note: 1 VehicleType can have multiple ValidConfigs
class VehicleType{
List<ValidConfigs> validConfigs;
public boolean isValidAssignments(Collection<Assignments>);
}
then in your score rule:
rule
when
$v : Vehicle($vt : vehicleType)
$aList: collect from Assignment(vehicle == $v) // see drools docs for
correct syntax
eval($vt.isValidAssignments($aList))
then
On 12-09-13 05:37, Andrew Varner wrote:
Here's the problem I am trying to solve.
My users provide me a a list of configurations for what a truck can hold. For example:
PickupTruck:
1xLargeSofa
3xSmallChair
PickupTruck:
1xLargeSofa
1xSmallSofa
1xSmallChair
PickupTruck:
5xSmallChair
TractorTrailer:
2xLargeSofa
4xSmallChair
…
The also give me the inventory of the a furniture store. I am using a set of rules
(Drools) to determine which ones are the best to throw on the next vehicle. So if a
PickupTruck arrives, I calculate for each truck configuration I have to see which sofa,
chair, etc. goes on it.
My current plan is to convert the truck configuration (essentially a domain specific
language) into a PlanningEnity
The first configuration translates to:
//PickupTruck:
//1xLargeSofa
//3xSmallChair
public class PickupTruck1(){
private String type="PickupTruck";
private String description = "PickupTruck:1xLargeSofa,3xSmallChair";
private Furniture furniture1;
private Furniture furniture2;
private Furniture furniture3;
private Furniture furniture4;
@PlanningVariable(valueRangeProviderRefs = {"largeSofa"})
public Furniture getFurniture1() {
…
}
@PlanningVariable(valueRangeProviderRefs = {"smallChair"})
public Furniture getFurniture2() {
…
}
@PlanningVariable(valueRangeProviderRefs = {"smallChair"})
public Furniture getFurniture3() {
…
}
@PlanningVariable(valueRangeProviderRefs = {"smallChair"})
public Furniture getFurniture4() {
…
}
}
My gut feeling is that this is faster/better than trying to put a chair in a sofa slot,
than using a generic "Furniture" provider, but I could be wrong. I'd like to
have a single class that parses the inventory and provides them as value ranges. Of
course, I could transform the inventory into a @PlanningSolution and compile it. However,
I'd rather not.
Also, looking at this now, I realize that the provider may provide me the same small
chair in all three slots (doh!).
Does this make sense?
Thanks,
Drew
On Sep 10, 2013, at 3:10 AM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
> On 09-09-13 16:13, Andrew Varner wrote:
>> Optaplanners,
>>
>> I'm looking to add some dynamic goodness to ValueRangeProvider. The only way
I see to specify a ValueRangeProvider is via annotation.
>>
>> I'd like to be able to generate the id and Collection of candidate values
dynamically. Is it possible to generate the ValueRangeProvider data outside of an
annotation?
>>
>> For example:
>>
>> public class MyDataSource {
>> public Collection getValues(String id) {
>> …
>> return values;
>> }
>> }
> First, I thought you were asking for this issue:
>
https://issues.jboss.org/browse/PLANNER-190
> That would allow you to generate the Collection dynamically (although
> you can already do that now with an entity based value range and
> somewhat with a solution based value range).
>
> But you want to "generate the id of ValueRangeProvider dynamically"?!
> Interesting :) Why?
> That implies that you also want to generate the planning entities and
> their variables dynamically,
> because there's no use in generating a provider id if you're not going
> to use it.
> Long term we 'll support this because we'll support an alternative to
> annotations too,
> but why does your use case need it now?
>
>
>
> Also, you might want to read these references:
>
http://stackoverflow.com/questions/18343221/does-optaplanner-support-opti...
>
https://issues.jboss.org/browse/PLANNER-160
> Note: 160 won't allow you to generate the value provider id at runtime.
>> Thanks,
>> Drew
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users