Re: [Help-glpk] problem with glp_ios_heur_sol

[Le Dinh Danh]

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
>>>>>>
>>>>>> 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 <address@hidden> 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 <address@hidden> ha
>>>>>>> scritto:
>>>>>>>
>>>>>>> Hi Giorgio Sartor,
>>>>>>>
>>>>>>> On Mon, Aug 5, 2013 at 4:14 PM, Giorgio Sartor <address@hidden>
>>>>>>> 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 <address@hidden>
>>>>>>>> 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 <address@hidden>
>>>>>>>> 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 <address@hidden>
>>>>>>>>> ha scritto:
>>>>>>>>>
>>>>>>>>>> the result is still incorrect.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Le Dinh Danh
>>>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
>>>>>>>> Email: address@hidden; address@hidden
>>>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Le Dinh Danh
>>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
>>>>>>> Email: address@hidden; address@hidden
>>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Le Dinh Danh
>>>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
>>>>>> Email: address@hidden; address@hidden
>>>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66
>>>>
>>>>
>>>>
>>>> --
>>>> Le Dinh Danh
>>>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
>>>> Email: address@hidden; address@hidden
>>>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66
>>
>>
>>
>> --
>> Le Dinh Danh
>> LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
>> Email: address@hidden; address@hidden
>> Tel: (+84) 912.449.666; (+33) 6.52.98.59.66



-- 
Le Dinh Danh
LIRMM, 161 rue Ada, 34095 Montpellier Cedex 5
Email: address@hidden; address@hidden
Tel: (+84) 912.449.666; (+33) 6.52.98.59.66