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
