[FlopCpp] Problem using FlopC++ with GLPK

Renato Bruni bruni at diei.unipg.it
Fri Sep 18 05:42:14 EDT 2009


Thanks for your help. I also find very useful every suggestion like the
following.

> One more comment on the example: in many situations, I would find it
> more practical to replace
> modello.maximize( x(0) + x(1) + x(2) );
> by
> modello.setObjective( x(0) + x(1) + x(4) );
> modello.attach();
> modello.maximize();

In fact, I would be glad to find something like a collection of suggestions
for using FlopC++, i.e. a user's manual, but I was not able to find it.
 I also noticed that the same FlopC++ code, that may look correct to me, may
be understood in the right way by some solver but in the wrong way by some
other solver, without having error messages in compilation. I have of course
the doxydoc documentation, but I could not learn about those points from
that. Does anybody have something like a user's manual, even some personal
collection of notes and pro memoria for using FlopC++ with different solvers
(and in particular GLPK, which seems to have peculiar behaviour for some
things)? Something saying "if you need to add constraints so and so, with
cbc do so, with glpk do so, and so on". I would appreciate that very much.
Thanks a lot.
Renato Bruni

----- Original Message ----- 
From: "Michal Kaut" <mail at michalkaut.net>
To: "Renato Bruni" <renato.bruni at diei.unipg.it>
Cc: <flopcpp at list.coin-or.org>
Sent: Thursday, September 17, 2009 9:03 PM
Subject: Re: [FlopCpp] Problem using FlopC++ with GLPK


>I think I have found the problem and solution - I tested it only on the
> first example. It turned out to be a combination of the following:
> 1. Osi uses upper-bound = infinity to denote unlimited variables.
> 2. Each solver uses a different value for infinity.
> 3. Since FlopC++ has to be able to initialize variables even before it
> has a solver attached, it uses 1e30 as a default (which, I believe, is
> Clp's infinity). (One could argue that you have solver attached from the
> beginning and hence it should be possible to set the correct infinity ..
> well, feel free to update the code.)
> 3. glpk's uses 9.9e32, so it will work with the 1e30 upper bounds as
> values. This is asking for numerical problems.
> 4. glpk does not recognize it has problems and happily report a wrong
> solution
>
> So, the bottom line is that if you have unbounded variables, you should
> always change their upper bounds to the solver's infinity.
> In the case of the first example, just add
> x.upperLimit(N) = modello.getInfinity();
> to the model. (Note that you can also use modello->getInfinity(), since
> the -> operator gives you the Osi object and it has the same function.)
>
>
> One more comment on the example: in many situations, I would find it
> more practical to replace
> modello.maximize( x(0) + x(1) + x(2) );
> by
> modello.setObjective( x(0) + x(1) + x(4) );
> modello.attach();
> modello.maximize();
> The reason is that the attach() method creates an Osi object, so one can
> use all the Osi methods to work with it (using the overloaded '->'
> operator). You can, for example, write an MPS file:
> modello->writeMps("test");
> You can also replace the maximize() method and start by solving an LP
> relaxation of the problem:
> modello->setObjSense(MP_model::MAXIMIZE);
> modello->initialSolve();
> modello->branchAndBound();
>
>
> Hope this helped.
>
> Regards,
> Michal
>
>
> Renato Bruni wrote:
>> Hello everybody,
>>
>> we have some strange behaviour using FlopC++ 1.0.6 (having inside Osi
>> 0.100.0) and GLPK 4.38.
>>
>> If we run the following example, with 5 variables and 2 constraints, we
>> obtain solution x=(0, 2, 0, 0, 0) and objective= 2
>> but the solution should be x=(4, 0, 0, 0, 0) and objective= 4
>>
>> #include "flopc.hpp"
>> using namespace flopc;
>> #include <OsiGlpkSolverInterface.hpp>
>>
>> int main() {
>>     MP_model modello(new OsiGlpkSolverInterface);
>>     MP_set N(5);
>>     MP_variable x(N);
>>     x.integer();
>>
>>     MP_constraint vinc1;
>>     MP_constraint vinc2;
>>     vinc1 = 2*x(0) + 4*x(1) + 6*x(4) == 8;
>>     vinc2 = x(0) + x(4) <= 100;
>>     modello.add(vinc1);
>>     modello.add(vinc2);
>>
>>     modello.maximize( x(0) + x(1) + x(4) );
>>     x.display("Optimal solution per x:");
>> }
>>
>> If we run this other example, that is the same model with 5 variables and
>> 2 constraints, we obtain solution x=(4, 0, 0, 0, 96) and objective= 4
>> but the solution should be, like before, x=(4, 0, 0, 0, 0) and objective=
>> 4
>>
>> #include "flopc.hpp"
>> using namespace flopc;
>> #include <OsiGlpkSolverInterface.hpp>
>>
>> int main() {
>>     MP_model modello(new OsiGlpkSolverInterface);
>>     MP_set N(5);
>>     MP_set S(5);
>>     MP_subset<1> Sub(S);
>>     Sub.insert(0);
>>     Sub.insert(1);
>>     Sub.insert(4);
>>
>>     MP_variable x(N);
>>     x.integer();
>>
>>     MP_data COEFF(Sub);
>> int i;
>> for(i=0; i<Sub.size();i++)
>> COEFF(i)= 2*(i+1);//vector COEFF={2,4,6}
>>     COEFF.display("COEFF ");
>>
>>     MP_constraint vinc1;
>>     MP_constraint vinc2;
>>     vinc1 = sum(Sub, COEFF(Sub)*x(Sub))==8;//2x0+4x1+6x4==8
>>     vinc2 = x(0) + x(4) <= 100;
>>     modello.add(vinc1);
>>     modello.add(vinc2);
>>
>>     modello.maximize( sum(Sub, x(Sub)) );//max(x(0)+x(1)+x(4))
>>    x.display("Optimal solution per x:");
>> }
>>
>> Which can be the reason(s) of this incorrect behaviour?
>> Are there incompatibilities between the versions of FlopC++ 1.0.6 and
>> GLPK
>> 4.38? In this case, which version of GLPK should be used?
>>
>> Thanks for your help.
>> Best regards,
>> Renato Bruni
>>
>>
>> _______________________________________________
>> FlopCpp mailing list
>> FlopCpp at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/flopcpp
>>
>> -------------------------------------------
>> Modern Hosting PIPNI - http://www.pipni.cz/
>
> _______________________________________________
> FlopCpp mailing list
> FlopCpp at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/flopcpp



More information about the FlopCpp mailing list