LPSolve error?
Hi,
I've written a simple LPSolve test program. But it seems to fail to give me the correct answer that satisfy the constraints. Here is the code:
with(Optimization):
cnsts := {x1 + x2 + x3 + x4 + x5 >= 1, x1+x2+x3+x11+x6 >= 1, x7+x9+x10+x4+x5 >=1, x7+x9+x10+x4+x5 >= 1, x7+x9+x10+x11+x6 >=1, x8 + x9 + x10+x4+x5 >=1, x8+x9+x10+x11+x6 >=1};
obj := x1+x2+x3+x4+x5+x6+x7+x8+x9+x10+x11;
LPSolve(obj,cnsts,assume = {nonnegative});
The answer I get is:
[1.9999999989674, [x1 = 0., x2 = 0.99999999896740222, x11 = 0., x6 = 0., x7 = 0., x9 = 0.99999999896740222, x10 = 0., x8 = 0., x3 = 0., x4 = 1.03259778874000004 *10^(-9) , x5 = 0.]]
which doesn't staisfy the 2nd, 5th and last constraints.
Could you please try and verify this? Thanks a lot!
- restart:
with(plots):
spacecu
32 min 19 sec ago - to Robert Israel:
yes,
2 hours 6 min ago - to acer:
Yes, it is
2 hours 20 min ago - I agree
2 hours 28 min ago - simpler
2 hours 41 min ago - Not that way
3 hours 36 sec ago - Eigenvectors
3 hours 10 min ago - Thanks, acer,
I find another
4 hours 18 min ago - interesting idea
7 hours 21 min ago - interesting
7 hours 24 min ago
- Job offer / Stellenangebot: Technischer Support Maple
- Table from procedure
- Maple Mentor Awards: The Big Kahuna
- The actual architecture
- new package adoption
- Conjectures ripe for Maple experimentation
- overloaded operators
- poll: change in Maple that you want most?
- The future of FourierTrigSeries package
- Maple 12.01 is now Available
Rounding
As usual in such cases, the answers should be rounded, and after that will satisfy the constraints.
Alec
Exact solution
Since LPSolve works with floats, roundoff error is to be expected. In this case the problem itself does not involve floats and is quite small, so if you want an exact rational solution you can try the old simplex package.
{x1 = 1, x10 = 1, x11 = 0, x2 = 0, x3 = 0, x4 = 0, x5 = 0, x6 = 0, x7 = 0, x8 = 0, x9 = 0}
Not too surprisingly, this is the solution obtained by rounding the results of LPSolve, as Alec mentioned. Of course there will be other cases where the optimal solution does not involve integers, so rounding may not be helpful.
I don't understand
simplex[minimize](obj, cnsts, NONNEGATIVE);
{x1 = 1, x10 = 1, x11 = 0, x2 = 0, x3 = 0, x4 = 0, x5 = 0, x6 = 0, x7 = 0, x8 = 0, x9 = 0}
This is the correct and accurate solution to my original question. How come the accurate solution is obtained by rounding? That floating answer is not correct at all...
Why don't you understand?
This is a correct and accurate solution, but not the only one. The solution you got from LPSolve was
[x1 = 0., x2 = 0.99999999896740222, x11 = 0., x6 = 0., x7 = 0., x9 = 0.99999999896740222, x10 = 0., x8 = 0., x3 = 0., x4 = 1.03259778874000004 *10^(-9) , x5 = 0.]
which rounds to
[x1 = 0, x2 = 1, x3 = 0, x4 = 0, x5 = 0, x6 = 0, x7 = 0, x8 = 0, x9 = 1, x10 = 0, x11 = 0]
which is also a correct solution. You say "That floating answer is not correct at all", but it really is very close to correct: some of the constraints are violated by about 10^(-9).
Rounding to Digits/2
I often do rounding (or evalfing) to Digits/2 digits. That seems to be working OK with procedures in the Optimization package.
Alec