help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Help-glpk] Embedding GLPK to user application


From: design
Subject: RE: [Help-glpk] Embedding GLPK to user application
Date: Tue, 28 Oct 2008 21:32:29 +0300

There is no same problem on using "lp_solve".  This package has 3
callbacks which set up by follow functions: 
"put_logfunc" - catch terminal output,
"put_msgfunc" - catch solution improving and somewhat else,
"put_abortfunc" -  "interaction" with user (each simplex iteration).
So, user in real-time can see logs and current feasible solution, and do
another action during solving process. In addition user can halt
solution process in any moment of time. Unfortunately, there is no
analog of "abortfunc" function in your package. Real-life abort-function
of "lp_solve" you can see below:
****************
Function abortfunc(ByVal lp As Long, ByVal aborthandle As Long) As Long
  If Abs(Timer - t) > 0.2 Then     ' Åñëè ïðîøëî 0.2 ñåêóäíû
    SetInfo lp                     ' Îáíîâèòü èíôîðìàöèþ äëÿ îòîáðàæåíèÿ
ïîëüçîâàòåëþ
    mAgent.UpdateView True         ' Îáíîâèòü èíôîðìàöèþ íà ýêðàíå
    If (mAgent.BreakFlags And npb_Halt + npb_Break) <> 0 Then ' Åñëè
ïîëüçîâàòåëü ðåøèë ïðåðâàòü ïîèñê
      abortfunc = -1               ' Òî âûõîäèì èç ïîèñêà ðåøåíèÿ
    End If
    t = Timer                      ' Ñîõðàíÿåì âðåìÿ îáíîâëåíèÿ
èíôîðìàöèè äëÿ ïîëüçîâàòåëÿ
  Else
    abortfunc = 0
  End If
End Function
*****************

If I put solving procedure to separate thread then I will get follow
issues:
1. How to halt hard "LP-problem" (not MILP) solving process? Should I
kill a solving thread? In that case how to release memory of this
thread?
2. How to synchronize main thread and solving thread inside of callback
function? Should I correct GLPK and put semaphores to its code?
3. How to get information about solving process during long-time
"LP-problem" solving? Again semaphores in code of GLPK?
4. How to debug this solution? VB6 IDE will crash on debug in callback
functions...

A lot of jobs, a lot of problems...  Patching codes of GLPK (creation
abort function analog) are cheaper for me


-----Original Message-----
From: Andrew Makhorin [mailto:address@hidden 
Sent: Monday, October 27, 2008 9:23 PM
To: address@hidden
Cc: address@hidden
Subject: Re: [Help-glpk] Embedding GLPK to user application

> Andrew, I understand that interface for embedding to applications is
not
> interesting for you. Nevertheless this is a real problem of GLPK
because
> it is hostile to calling application. Developing separate thread is
very
> costly for me because my program already developed on vb6.

I am not an expert in VB, however I do not think this is an issue. See,
for example, the following article:
http://msdn.microsoft.com/en-us/library/aa719109.aspx

In your previous post you mentioned lp_solve. Do not you encounter the
same problem on using it in your application?

> Now I see that I should myself put somewhere callback function to code
of
> GLKP (as was recommend by Xypron). And correct code for each new
version
> of GLPK. And all programmers for all new versions should correct code
if
> GLPK is embedded to his application.

I do not think that patching the glpk source code is a good idea. There
must be a more acceptable way to resolve the issue.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]