1) It has better results, especially when scaling out. The OR competitions show this clearly. For example: 1a) In the google roadef competition, the top 80 teams competed for 20k € prize money, of which 10k € reserved excluded for the open source category. All LP based implementations (Choco, CPLEX, ...) mostly blew up on the B datasets. Metaheuristics clearly dominate the top ranking. Although custom written code by the super experts won, of all the production-ready solvers, I've seen none do better than Planner's latest results yet (including LocalSolver): http://blog.athico.com/2012/06/roadef-2012-first-results-for-dataset-b.html 1b) Also check the results on other competitions, such as ITC2007 ( http://www.cs.qub.ac.uk/itc2007 ). 2) It's far more flexible and easier to write your constraints. JaCop and Choco require you to write your constraints as mathematical equations (a requirement of LP). In Planner, you can write you constraints as a simple java method calculateScore, or as Drools rules (which are much faster due to incremental score calculation). This means you can add non linear constraints too. For example minimize the sum of x² (which is really useful for fairness constraints). Also, Planner's score constraints are Object-Orientated and allow you to reuse existing Java code. For example, you can reuse this Java method to check if an Employee is free on a certain date, based on the employee's country: isNationalHoliday(Date, Country) 3) The Score system is much more flexible. In JaCop and Choco, you can only implement 2 score levels: hard and soft. The inequalities are the hard constraints and their score function is the soft constraints. IIRC, both are based on java doubles and don't support other types (such as a BigDecimal for financial data). In Planner, you can use more score levels and other datatypes if so desired by defining your own ScoreDefinition. Out-of-the-box several basic ones are implemented. Op 21-08-12 10:17, zjg_robin schreef: -- With kind regards, Geoffrey De Smet

My 2 cents on some side aspects of this debate (which I leave to Geoffrey :)) Most LP solvers are written in C/C++, which is great for efficiency but also a limitation on portability and platform (in)dependence. Provided that you find a version of the code that compiles in your specific environment. There are a couple of java interfaces (e.g. GLPK), but they do not solve the problem. I run a linux-64 ubuntu machine and had a VERY HARD time last time I tried ( ~1 year ago ) Choco is written in java and has a very permissive license model, unlike the others which are either commercial or GPLx, but the last time I tried it ( ~6 months ago ) it was still suffering from some numerical computation problems. I had it almost stuck in a local plateau for several seconds while trying to solve a small minimization problem with ~4 variables and ~10 constraints. @Geoffrey: but can Planner be used effectively - i.e. with little overhead - for LP optimization problems, including the integer-LP and the mixed-LP variants? And quadratic ones? -- View this message in context: http://drools.46999.n3.nabble.com/What-s-the-difference-between-Drools-an... Sent from the Drools: User forum mailing list archive at Nabble.com.

Op 22-08-12 03:25, zjg_robin schreef: You only need those other object data structures if your constraints need them. They make your constraints readable and object orientated. Think about it, for example defining the dayOffRequest constraint: In Planner you base it on a DayOffRequest class and a ShiftAssignment class, by using DayOffRequest.getEmployee() and DayOffRequest.getShiftDate(). In LP based solvers, there is no DayOffRequest class and a ShiftAssignment class, instead they are represented as ints, int arrays or even arrays of arrays of ints. No code encapsulation, no OO. In fact, you have to manually translate id's into indexes (because id's have gaps and indexes can't have gaps). For example, in Planner you write it like this. Notice that you can read it. // Requested day on/off rule "dayOffRequest" when $dayOffRequest : DayOffRequest($e : employee, $d : shiftDate) $assignment : ShiftAssignment(employee == $e, shiftDate == $d) then ... // dayOffPenalty = $dayOffRequest.getWeight() end Notice how $dayOffRequest and $assignment are typed variables. In LP you have to write: dayOffPenalty <- sum[dayOffRequestArray in dayOffRequestArrays](shiftAssignmentArray[employeeIndexFromId[dayOffRequestArray[0]]][dayOffRequestArray[1]] * dayOffRequestArray[2]); Notice how the "dayOffRequestArray[2]" magically means it's the weight. What do "dayOffRequestArray[1]" and "dayOffRequestArray[0]" mean? What if the weight is a BigDecimal instead of an int? And despite lacking that mathematical equation, Planner has better results (as shown in the competitions :)