RE: [Help-glpk] loop for mathprog

[Meketon, Marc]

I view that MATHPROG serves two somewhat distinct functions:
(1) A data and set manipulation language
(2) A model (matrix) generating tool.

And AMPL adds a third function:
(3) Model/solution manipulation language

To me, (3) is the natural evolution of (1) and (2).

My uses of GLPK would have been easier and quicker to develop had
MATHPROG had a control language.  These "real world" problems involve
solving multiple optimization programs iteratively.  The type of script
that Bob has below is conceptually very common.

The concept of using extensions to Perl (c.f. Gabor Retvari) or other
languages with built-in associative arrays is a reasonable idea, but
MATHPROG/AMPL has these associative arrays already built-in and it nice
to keep it all together.

-Marc

-----Original Message-----
From: Robert Fourer [mailto:address@hidden 
Sent: Wednesday, November 15, 2006 13:18
To: 'Michael Hennebry'; 'Andrew Makhorin'
Cc: 'CADI Abdelahd'; address@hidden; Meketon, Marc
Subject: RE: [Help-glpk] loop for mathprog

Mike,

How would what you want differ from the ability to write a script such
as the
one copied below?  It's a simple script for sensitivity analysis --
there are
much more complicated examples -- but it serves as an example of how a
modeling
language's own syntax could serve well as a scripting language.
Conversion
between variable names and variable indices is not an issue here,
because the
user writes everything in terms of the symbolic model.

I have some sympathy for Andrew's view (see the copied message below),
but
maybe I see the tradeoff differently.  It's a tradeoff between having
essentially the same language serving for both model definitions and
script
writing, and having a general-purpose programming language that works
through
an API to handle models written in a modeling language.  I have
encountered
optimization modelers on each side of this tradeoff.

Bob Fourer
address@hidden


model steelT.mod;
data steelT.dat;

option solution_precision 10;
option solver_msg 0;

set AVAIL3 default {};
param avail3_obj {AVAIL3};
param avail3_dual {AVAIL3};

let avail[3] := 0;
param previous_dual default Infinity;

repeat {
   let avail[3] := avail[3] + 1;
   solve;
   if Time[3].dual = previous_dual then continue;

   let AVAIL3 := AVAIL3 union {avail[3]};
   let avail3_obj[avail[3]] := Total_Profit;
   let avail3_dual[avail[3]] := Time[3].dual;
   if Time[3].dual = 0 then break;

   let previous_dual := Time[3].dual;
}
display avail3_obj, avail3_dual;


> -----Original Message-----
> From: address@hidden
[mailto:help-glpk-
> address@hidden On Behalf Of Michael
Hennebry
> Sent: Tuesday, November 14, 2006 1:10 PM
> To: Andrew Makhorin
> Cc: CADI Abdelahd; address@hidden; Meketon, Marc
> Subject: Re: [Help-glpk] loop for for mathprog
> 
> On Tue, 14 Nov 2006, Andrew Makhorin wrote:
> 
> > There is a dilemma, because I do not think that mixing modeling
> > and "programming" capabilities within model description (as in
> > AMPL) is a good idea; on the other hand I would like to keep
> > compatibility between GNU MathProg and AMPL. Probably, there must be
> > another level, something like a script, that allows performing all
> > operations needed for reoptimization and post-optimal processing.
> 
> In my optimization work, I almost always use the
> API of a solver instead of a modeling language.
> The reason is that I usually want to solve another
> problem related to the first and its solution.
> Absent a reliable mechanism for converting variable
> names to variable indices this can be difficult.
> Being able to do the following from within code would be a good thing:
> read a problem specified in a modeling language
> solve problem
> update problem
> solve problem
> rinse and repeat as necessary
> print solution in convenient form.
> 
> Being able to convert names to indices would facilitate
> the update problem and print solution steps.
> 
> It's been a release or two since I last used GLPK,
> so if it now has and documents the aforementioned mechanism,
> never mind.
> 
> --
> Mike   address@hidden
> "it stands to reason that they weren't always called the ancients."
>                                                       --  Daniel
Jackson
> 
> 
> 
> _______________________________________________
> 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.
----------------------------------------------------------------------------