MaplePrimes - answers and comments on Question, LPSolve Matrix Form

what's the problem?

pagan — Thu, 29 Dec 2011 11:18:36 Z

The notation of c'x for the objective is just shorthand for a Vector dot product. It's a scalar, the result of the dot product of the row Vector c' (ie. the transpose of column Vector c) and the column Vector x. The entries of Vector c are the numeric coefficients, and the Vector x are the as-yet-unknown variables. Hence c'x is a linear combination -- not surprising as we are talking about Linear Programming problems.

So, in Matrix form, the Vector x for you example will have as it entries all the w[i] as well as dr and ur. But since for your example the objective c'x is just the linear combination ur + dr = 0*w[1]+0*w[2]+...+0*w[50]+1.0*ur+1.0*dr then it is easy to see how to construct both c and x as Vectors.

The Vector c might be taken as Vector(52,i->`if`(i=51 or i=52, 1.0, 0.0))

The Vector x would then be taken as Vector(52,i->`if`(i=51,dr,`if`(i=52,ur,w[i])))

c:=Vector(52,i->`if`(i=51 or i=52, 1.0, 0.0)):
x:=Vector(52,i->`if`(i=51,dr,`if`(i=52,ur,w[i]))):

c^%T . x;
                        1.0 dr + 1.0 ur

It is trivial to adjust, for a maximation problem.

And now that you know what are the entries of the Vector x of unknowns, you can see the LPSolve Matrix form help page for how to set up the linear constraints and simple bounds.

If you are interested in efficiency, then use the syntax z[i,1] to access the entries of Matrix z, as the syntax z[i][1] is quite an inefficient way to get the same thing. When you invoke z[i][1] you force Maple to waste resources extracting z[i] (which is the i'th row of z) as a new Vector object whose transient existence serves only to have its first entry extracted. But the syntax z[i,1] extracts the first entry in the i'th row directly, as a mere scalar. So, one way forms a new Vector (which takes resources to form as well as to collect and dispose of as garbage) just to extract a single scalar entry, while the other method simply extracts that same desired scalar entry directly with no such addtional overhead.

Ok, this is what I got so far. The first

alex_01 — Thu, 29 Dec 2011 18:11:47 Z

Ok, this is what I got so far. The first constraint is working (I think)
Constraint number 2 and 3 on the otherhand is not working.

The second constraint gives an error message: cannot store ur in a floating-point r-table
The third constraint needs to be broken down in to many separate constrains I think

restart:
randomize():
with(Optimization):
with(Statistics):
with(LinearAlgebra):

N := 12:
R := RandomMatrix(N, outputoptions = [datatype = float[8]]):
ER := Vector[column]([seq(ExpectedValue(Column(R, j)), j = 1 .. N)]):

x := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1, dr, `if`(i = 2, ur, w[i])) end proc):
c := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1 or i = 2, 1.0, 0.) end proc):

# 1) I think this constraint is ok
Av := Matrix([[0, 0, seq(1, i = 1 .. N)]], datatype = float[8]):
bv := Vector([1], datatype = float[8]):
Av.x<bv;

# 2) This constraint most likely not ok since I get an error message;
# can not store ur in a floating-point r-table
Az := Transpose(`<,>`(Matrix([0]), Matrix([0]), ER)):
bz := Vector([ur]):
Az.x<bz;

# 3) This constraint is wrong as well. It becomes very difficult if you need to separate
# it into many different constraints ie [ Aq[1],bq,Aq[2],bq,.....Aq[N+2,bq ]
Aq := `<|>`(Vector([seq(0, i = 1 .. N+2)]), Vector([seq(0, i = 1 .. N+2)]), `<,>`(Matrix([seq(0, i = 1 .. N)]), Matrix([seq(0, i = 1 .. N)]), R)):
bq := Vector([0, 0, seq(dr, i = 1 .. 12)]):
Aq.x < bq ;

an example

acer — Thu, 05 Jan 2012 22:33:11 Z

Here is a short example which might help you interpret and see the relationship between the algebraic and Matrix forms accepted by LPSolve.

There is no exposed conversion utility (likely because one of the central purposes of the Matrix form is to never form the large expressions in the algebraic form at all). But you might experiment with the internal routine which I use below, in order to see what happens when there are no strict equality constraints, or no inequality constraints, or no simple variable bounds, and so on.

> restart:

> problem := -x-2*y, {7 >= 3*x+5*y, 113 >= -11*x-13*y, 17*x+19*y=23}, x=-29..31, y=-37..41:

> Optimization:-LPSolve(problem);

     [-2.92857142857143, [x = -0.642857142857142, y = 1.78571428571429]]

> kernelopts(opaquemodules=false):

> problem_matrix_form := Optimization:-Convert:-AlgebraicForm:-LPToMatrix(problem)[2..4];

        problem_matrix_form := [-1., -2.], 

          [[-11.  -13.]                               ]                            
          [[          ], [113., 7.], [17.  19.], [23.]], [[-29., -37.], [31., 41.]]
          [[  3.    5.]                               ]                            

> Optimization:-LPSolve(problem_matrix_form);

                  [                   [-0.642857142857142]]
                  [-2.92857142857143, [                  ]]
                  [                   [  1.78571428571429]]

[edited] I might as well just do it. The first two places represent variables ur and dr, and the remaining N places represent w[i], i=1..N.

restart:
randomize():

with(Optimization):
with(Statistics):
with(LinearAlgebra):

N := 500:
R := RandomMatrix(N, outputoptions = [datatype = float[8]]):
ER := Vector[column]([seq(ExpectedValue(Column(R, j)), j = 1 .. N)]):

# algebraic form
st:=time():
W := Vector(N, symbol = w):
S := Vector(N, fill = 1, datatype = float[8]):
z := Multiply(R, Matrix(W)):
con1 := Transpose(W).S = 1:
con4 := seq(z[i][1] - dr >= 0, i = 1 .. N):
con5 := expand(Transpose(W).ER) - ur >= 0:
sol1:=LPSolve(ur+dr, {con1, con4, con5}, seq(w[i]=0..1,i=1..N), maximize = true):
sol1[1];
                        2.68825855741790
time()-st;
                             6.296

# Matrix form
st:=time():
A:=Matrix(N+1,N+2,datatype=float[8]):
A[2..-1,3..-1]:=R:
A[2..-1,1]:=Vector(N,fill=-1,datatype=float[8]):
A[1,3..-1]:=ER:
A[1,2]:=-1:
MatrixScalarMultiply(A,-1,inplace):
b:=Vector(N+1,datatype = float[8]):
#A,b;
Aeq:=Matrix(1,N+2,fill=1,datatype=float[8]):
Aeq[1,1..2]:=Vector(2,datatype=float[8]):
beq:=Vector(1,[1],datatype=float[8]):
#Aeq,beq;
c:=Vector(N+2,[1,1],datatype=float[8]):
#c;
bl:=Vector(N+2,datatype=float[8]):
bl[1..2]:=Vector(2,fill=-infinity):
bu:=Vector(N+2,fill=1,datatype=float[8]):
bu[1..2]:=Vector(2,fill=infinity,datatype=float[8]):
#bl,bu;
sol2:=Optimization:-LPSolve(c,[A,b,Aeq,beq],[bl,bu],maximize = true):
sol2[1];
                        2.68825855741790
time()-st;
                             3.735

So, half the time, for N=500. There are also memory savings on the order of the size of all the constraints as symbolic expressions, which I didn't bother to measure. There might be a relatively small bit more time saved, using ArrayTools routines like BlockCopy and Fill.

acer

I am grateful for your loyal support.

alex_01 — Thu, 29 Dec 2011 14:09:49 Z

I am grateful for your loyal support. I think that setting up a complex problem in
LP[Matrix Form] notation is extremly complicated. My brain really hurts. I just wish
that Maple did not separate between algebraic and matrix form ie if algebraic form
is entered then maple could convert it to matrix form and solve the problem
most efficiently. Now you have the option; Do you want to solve inefficiently
or efficiently? It does not really make any sense to give the user access to inefficiency.
Any how.......

This is as far as i got. I am having problems with the Aq,bq,Az,bz inequality constraints.
For Aq,bq I dont think I can reference z directly I have to do some transformation hummm
Also Aq.x>bq and Az.x>bz however by default Aq.x<bq and Az.x<bz, which is not what I
want. How can you get around that?

It would be nice to be able to show that both LP[algebraic form] and LP[matrix form]
produces the same results....

restart:
randomize():
with(Optimization):
with(Statistics):
with(LinearAlgebra):

N := 12:
W := Vector(N, symbol = w):
R := RandomMatrix(N, outputoptions = [datatype = float[8]]):
ER := Vector[column]([seq(ExpectedValue(Column(R, j)), j = 1 .. N)]):
S := Vector(N, fill = 1, datatype = float[8]):
z := Multiply(R, Matrix(W)):

con1 := Transpose(W).S = 1:
con2 := seq(w[i] >= 0, i = 1 .. N):
con3 := seq(w[i] <= 1, i = 1 .. N):
con4 := seq(z[i, 1] >= dr, i = 1 .. N):
con5 := expand(Transpose(W).ER) >= ur:

LPSolve(ur+dr, {con1, con2, con3, con4, con5}, maximize = true);

x := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1, dr, `if`(i = 2, ur, w[i])) end proc):
c := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1 or i = 2, 1.0, 0.) end proc):

Av := Matrix([[0, 0, seq(1, i = 1 .. N)]], datatype = float[8]):
bv := Vector([1], datatype = float[8]):

# problem constraints (linear inequality constraints)
Aq := Matrix([[0, 0, seq(z[i, 1], i = 1 .. N)]]):
bq := Vector([dr]):
Az := Matrix([[0, 0, seq(z[i, 1], i = 1 .. N)]]):
bz := Vector([ur]):

bl := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1, -20, `if`(i = 2, -20, 0.)) end proc):
bu := Vector(N+2, proc (i) options operator, arrow; `if`(i = 1, 20, `if`(i = 2, 20, 1.0)) end proc):

LPSolve(c, [Av, bv, Aq, bq, Az, bz], [bl, bu], maximize = true);

a matter of the set up, not the solving

pagan — Thu, 29 Dec 2011 20:02:11 Z

@alex_01 The whole efficiency question for Matrix-form vs algebraic-form has to do with the problem setup, not with the actual solving stage.

The Optimization routine converts the algebraic form into Matrix form, before passing it externally to the compiled solver. The external, compiled solver only knows how to work with the Matrix form which is comprised purely of collections of floating-point numbers.

The inefficiency is thus in the forming of the algebraic form, in the storing of the algebraic form entities in Maple (takes more memory than does the Matrix form), and in the decomposing of the algebraic form into the Matrix form.

If you can formulate the problem directly in Matrix form, then you have saved resources. If, however, you form it in algebraic form, only to then manually convert it to Matrix form yourself, then you have saved nothing over what Optimization itself would do internally.

Perhaps your problems will not be huge enough for all this to matter so much?

Good luck, and a Happy New Year to you and yours!

hummm

alex_01 — Thu, 29 Dec 2011 20:41:26 Z

@pagan If Maple automatically convert the problem into LP[matrix form] why cant
Maple show me the output of such matrix form conversion?

Then I could i) specify the LP in the usuall manner ii) have maple convert it
to matrix form iii) look at the output from such convertion iiii) respecify the
problem as iii)

That would save a lot of headache. I know Maple has functions like
GenerateMatrix() but it is still difficult.

My main problem now is that Maple cant store dr and ur in floating point r-tables
hence I doubt that my problem can be solved even though if I specify it in the
usuall manner Maple manage to convert it to matrix form hence it should be
doable. I am confused.....

PS Speed is critical in this calculation, hence matrix form LP is important.