Re: [Help-glpk] Embedded Python in GLPK

[Michael Hennebry]

On Thu, 13 Mar 2008, vijay patil wrote:

> On Sun, Mar 9, 2008 at 4:46 AM, Xypron <address@hidden> wrote:

> > Where do I want to go to: I would like to use embedding Python scripting
> > to control the solution process: adding new constraints, changing
> > variables from float to binary, ...  But that is future. Currently
> > Python can only used to calculate numbers, symbols and sets.
> >
> > I am looking forward for Your comments.
> >
> >
> I will try out this just for fun. As far as know, in real life mathematical
> programming languages (like MathProg, OPL etc.) are used only for prototype
> purpose (correct me if I am wrong), just to quickly and easily try out
> different model formulations. The final model is usually coded using C API
> provided by the solver. In other words, final application is likely to be a
> C/C++/Java program.

That might be true, but I don't know why.
A quote from "Basics of Unix Philosophy" (I did some hand-formatting):
> Rule of Economy: Programmer time is expensive;
> conserve it in preference to machine time.
> ...
> Somehow, though, practice doesn't seem to have quite caught up with
> reality. If we took this maxim really seriously throughout software
> development, most applications would be written in higher-level
> languages like Perl, Tcl, Python, Java, Lisp and even shell .
> languages that ease the programmer's burden by doing their own
> memory management (see [Ravenbrook]).
>
> And indeed this is happening within the Unix world,
> though outside it most applications shops still seem
> stuck with the old-school Unix strategy of coding in
> C (or C++). Later in this book we'll discuss this
> strategy and its tradeoffs in detail.

On Thu, 13 Mar 2008, vijay patil wrote:
> Real life applications involve lot of data processing and many types of
> constraints. Adding these constraints require suitable data structures and
> functions. Also sometimes customized branch and bound algorithm might be
> needed to solve specific mixed integer program and interaction with GUI.
> Writing the whole application in C/C++ gives tremendous flexibility.

If the problem generator doesn't use enough cycles to matter,
what it's coded in should be a matter of convenience for the
user and the author.

> I am really interested in knowing (and learning) what other people's
> experience are with usage of mathematical programming language vs using
> solver's C API.

I've mostly used the C API.
The reason is that I've usually been testing algorithms
involving iterative LP or iterative MILP.
I've needed to make a connection between the solver's
variable indices and my own, sometimes complicated, labels.
That can be tricky with a modeling language,
though I've done it on occasion.
That said, my problem generators could get rather complex.
It might have been better for me to generate a
text file with python for my C code to interpret.
The python and C needn't have been linked.
If done right, using a text file doesn't reduce
the accuracy of floating point numbers.
python is not a special case.
Your favorite language will also work.

My understanding is that calling C from python isn't too tough.
I haven't tried it myself.
If you want a callback routine to call python,
that might be harder.
I haven't tried that either.
Such code is likely to be run more often
than code that calls GLPK routines.
Thus its speed will be more important.
It might be good to look at Numeric.

-- 
Michael   address@hidden
"Those parts of the system that you can hit with a hammer (not advised)
are called Hardware;  those program instructions that you can only
curse at are called Software."