Just to clarify: glp_simplex : LP solution
glp_iocp.presolve = ON : LP solution + preprocessing - Gioker - Il giorno 06/ago/2013, alle ore 14:55, Le Dinh Danh <[email protected]> ha scritto: > OK, I find it clearer now, Thank you so much for your help man. Good work! > > On Tue, Aug 6, 2013 at 2:35 PM, Giorgio Sartor <[email protected]> wrote: >> The difference is the preprocessing. >> If the problem has, for example, x variables (say 192), it is possible that >> after preprocessing (activated with presolve) the problem has less than x >> variables (say 186). glp_ios_heur_sol would need 186 but you give him 192 >> variables. That's why you had those problems with initial solutions. >> >> >> - G. S. - >> >> Il giorno 06/ago/2013, alle ore 13:13, Le Dinh Danh <[email protected]> ha >> scritto: >> >>> Oh great! It works now. Thank you so much G.S. I try your way and it >>> is correct now. >>> However, I really don't know why. I thought that the default presolve >>> in GLPK using simplex method and it should work the same as we call >>> simplex solver (with parm.presolve = OFF). >>> It takes me a lot of time. Thank you once again and good work! >>> >>> On Tue, Aug 6, 2013 at 12:42 PM, Giorgio Sartor <[email protected]> wrote: >>>> Ok. I really think that the problem is the presolve because I had the same >>>> problem months ago. >>>> At least just try adding glp_simplex before glp_intopt and disable >>>> presolve. >>>> Presolve is not default in GLPK. >>>> >>>> >>>> - G. S. - >>>> >>>> Il giorno 06/ago/2013, alle ore 12:31, Le Dinh Danh <[email protected]> ha >>>> scritto: >>>> >>>>> Oh I forgot to tell you that I suppose to use the default presolve in >>>>> GLPK and do not explicit use any other for it. I know that if I don't >>>>> use the presolve default I have to use some presolve like simplex or >>>>> so. So in my case parm.presolve = ON is neccesary. >>>>> For my heuristic solutions I am sure that they are correct, because I >>>>> can verify it manually myself. >>>>> >>>>> On Tue, Aug 6, 2013 at 12:23 PM, Giorgio Sartor <[email protected]> >>>>> wrote: >>>>>> Well, I don't know what you mean exactly but setting parm.presolve = ON >>>>>> is >>>>>> never NECESSARY! (It is necessary only if you don't want to use >>>>>> glp_simplex >>>>>> before glp_intopt). If you don't use it, my suggestion is to use >>>>>> glp_simplex >>>>>> before glp_intopt and disable parm.presolve. In this case, if the integer >>>>>> solution found is incorrect means that the solution you pass is >>>>>> incorrect. >>>>>> >>>>>> >>>>>> 2013/8/6 Le Dinh Danh <[email protected]> >>>>>>> >>>>>>> Hi G.S, >>>>>>> It is neccesary to set parm.presolve=ON before solving MIP. In fact, >>>>>>> I've >>>>>>> tried with parm.presolve=OFF but the results are always 0. Anyway, thank >>>>>>> you. >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 5, 2013 at 5:34 PM, Giorgio Sartor <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Ok. Just try parm.presolve=OFF and let me know if then works. >>>>>>>> >>>>>>>> >>>>>>>> - G. S. - >>>>>>>> >>>>>>>> Il giorno 05/ago/2013, alle ore 16:51, Le Dinh Danh <[email protected]> >>>>>>>> ha >>>>>>>> scritto: >>>>>>>> >>>>>>>> Hi Giorgio Sartor, >>>>>>>> >>>>>>>> On Mon, Aug 5, 2013 at 4:14 PM, Giorgio Sartor <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Is glp_iocp.presolve activated? >>>>>>>> >>>>>>>> Yes, I have already set parm.presolve = ON. >>>>>>>>> >>>>>>>>> A common cause of incorrect solutions is that your solution is correct >>>>>>>>> for the original problem but not correct for the current problem >>>>>>>>> (which >>>>>>>>> could have been modified by GLPK during the solving process). >>>>>>>>> Stupid question: does your solution start from position 1 of the >>>>>>>>> array? >>>>>>>> >>>>>>>> Yes, of course. >>>>>>>>> >>>>>>>>> >>>>>>>>> - G. S. - >>>>>>>>> >>>>>>>>> Il giorno 05/ago/2013, alle ore 14:58, Le Dinh Danh <[email protected]> >>>>>>>>> ha scritto: >>>>>>>>> >>>>>>>>> With "the result is still incorrect" I mean after calling the callback >>>>>>>>> function, the solver find the solution but it is not correct one. I >>>>>>>>> don't >>>>>>>>> know why. If I don't call the cacllback, the solve provide a good >>>>>>>>> solution. >>>>>>>>> I can check it manually. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 5, 2013 at 1:19 PM, Giorgio Sartor <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> What do you mean with "the result is still incorrect"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - G. S. - >>>>>>>>>> >>>>>>>>>> Il giorno 05/ago/2013, alle ore 12:57, Le Dinh Danh >>>>>>>>>> <[email protected]> >>>>>>>>>> ha scritto: >>>>>>>>>> >>>>>>>>>>> the result is still incorrect. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Le Dinh Danh >>>>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 >>>>>>>>> Email: [email protected]; [email protected] >>>>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Le Dinh Danh >>>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 >>>>>>>> Email: [email protected]; [email protected] >>>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Le Dinh Danh >>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 >>>>>>> Email: [email protected]; [email protected] >>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 >>>>> >>>>> >>>>> >>>>> -- >>>>> Le Dinh Danh >>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 >>>>> Email: [email protected]; [email protected] >>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 >>> >>> >>> >>> -- >>> Le Dinh Danh >>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 >>> Email: [email protected]; [email protected] >>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 > > > > -- > Le Dinh Danh > LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5 > Email: [email protected]; [email protected] > Tel: (+84) 912.449.666; (+33) 6.52.98.59.66 _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
