help-glpk
[Top][All Lists]
Advanced

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

RE: Re: [Help-glpk] MySQL Support for GLPK 4.23


From: Meketon, Marc
Subject: RE: Re: [Help-glpk] MySQL Support for GLPK 4.23
Date: Tue, 6 Nov 2007 01:39:31 +0300

I think we've had this discussion in the past...

Keeping MathProg a pure declarative language significantly limits its
applicability.  In my experience, there are two main reasons to have
procedural statements in MathProg:

(1) Many linear programs are approximations to the "real" problem, and
when they are implemented they often run multiple times.  For example,
to do some initial rounding of values, or to slightly modify the
objective function.

(2) Master/subproblem algorithms.

Without control statements, we have to dip into lower-level approaches.
For example, I typically write my MathProg data generator in MS Access's
VBA (since I don't have Heinrich's database grabbing code), call the
solver, read in solutions in Access VBA, modify the problem, rewrite
data or the model, and rerun.  It would be so much simpler to keep the
iterations within MathProg.

Lastly, your suggestion for read/write will be useful in that I can stop
using my more cumbersome Access VBA routines to write the data section
and to read and parse the outputs.  But as I tried to say above, for
most problems I will still need some other programming language (such as
Access VBA) to coordinate between the various linear programs being
solved.

-Marc

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of Andrew Makhorin
Sent: Sunday, November 04, 2007 6:01 AM
To: address@hidden
Subject: Fwd: Re: [Help-glpk] MySQL Support for GLPK 4.23

Hi Heinrich,

Thank you for your efforts.

I think the table feature is too sophisticated. Probably it is
reasonable to have it in AMPL, which is a more or less full-featured
programming language (unlike its earlier versions). However, I would
like to keep MathProg being a declarative, not procedural language.

So it seems to me that it would be sufficient to implement the
following two statements: read and write.

The read statement is the following:

   read s, p1, p2, ..., pn from <data definition> ;

where s is a set (may be omitted), p1, p2, ..., pn are parameters,
<data definition> defines a text file, select query, etc. It is
assumed that data for this statement is coded as a table:

   i11 i12 ... i1m v11 v12 ... v1n
   i21 i22 ... i2m v21 v22 ... v2n
   . . .

where (ik1, ik2, ..., ikm) is m-tuple, which being read is added to
set s and used as index for corresponding parameters, vk1, ..., vkn
are values of parameter members.

The write statement is similar to the printf statement:

   write {...} e1, e2, ..., en to <data definition> ;

where e1, e2, ..., en are expressions.

What do you think about this?


Best regards,

Andrew Makhorin



_______________________________________________
Help-glpk mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-glpk
---------------------------------------------------------------------------- 
This e-mail and any attachments may be confidential or legally privileged.  If 
you received this message in error or are not the intended recipient, you 
should destroy the e-mail message and any attachments or copies, and you are 
prohibited from retaining, distributing, disclosing or using any information 
contained herein.  Please inform us of the erroneous delivery by return e-mail. 

Thank you for your cooperation.
---------------------------------------------------------------------------- 








reply via email to

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