Re: Adding if/then/else statement to GMPL
> Probably something like MPL (Math Programming > Language) developed by G.Dantzig in 70's is what you would like to > have; > see https://dl.acm.org/doi/10.1145/800184.810495 . > I've got a scanned copy of this Tech. Report (May 1968, 92 pages); so if someone is interested, I can post it via e-mail.
Re: Adding if/then/else statement to GMPL
Well said. Sent from my mobile On Aug 24, 2020, at 1:39 PM, Jeffrey Kantor wrote: Respectfully, and I very much appreciate the careful design of GMPL and its utility for creating ‘beautiful’ models, I have to disagree. What is being proposed, I think, is not a general purpose programming language, but rather extensions to GMPL making it more suitable to expressing well accepted models for important OR applications. Stock cutting is one example, but there are many others. GMPL is very well suited to documenting models and applications, especially for teaching and education. They’re short, to the point, and above all, largely self-documenting. Extending the language should and could maintain these attributes. zWithout these extensions, I fear that GMPL will whither on the vine in favor of precisely what you describe … modeling tools embedded in higher level languages like Python and Julia. My hope is the GMPL v2 would, like GMPL v1, something that, once created, stays fixed for decades. This is the advantage of a reference language for representing models, a role for which GMPL has been successful. Models embedded in Python, Julia, etc, typically require additional maintanece as the languages and extensive libraries evolve. With GMPL one doesn’t have to worry about that. On Aug 24, 2020, at 12:17 PM, Andrew Makhorin mailto:m...@gnu.org>> wrote: On Mon, 2020-08-24 at 14:00 +, Meketon, Marc wrote: I've always felt that GMPL needed if-then-else, for-loops, 'let' statements and the ability to re-solve to be a true modeling language. And Andrew has always disagreed. Many of the models that I create ultimately are 'iterative' where I need to take the results of one model and use it to setup another model. To me, that is also modeling. GMPL doesn't have it. So often, I use GMPL for an initial model - it is a wonderful language, and I find it faster to code than alternatives. But then when I 'get it right' I have to re-code it in PYOMO or PULP or write directly to an 'lp' file within a Python or C# or other language script. Having the ability to run, adjust variables, add/take away constraints, re-run would be extremely useful, and make GMPL more of a one-stop modeling language. I agree that programming features like "goto" (as well as its structured versions) sometimes are necessary, but in my opinion it should be another language. Probably something like MPL (Math Programming Language) developed by G.Dantzig in 70's is what you would like to have; see https://dl.acm.org/doi/10.1145/800184.810495 . The initial design of AMPL, which GNU MathProg is based on, is not suitable to make AMPL a full-featured programming language, and in my opinion all further additions just broke the design being incompatible with it. On the other hand, developing and implementing yet another (even domain-specific) programming language is not a good idea. I think that modeling features might be built *over* an appropriate programming language. A good example of such approach is the GNU LilyPond (a music engraving program; see https://lilypond.org/ ), where the domain- specific part is built over the Scheme programming language (a dialect of Lisp): in normal circumstances the user writes all things with domain-specific constructions, but if something unusual is needed, he/she may write things on a lower level directly in Scheme. Andrew Makhorin 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.
Re: best Python interface for GLPK
Am 24. August 2020 19:35:25 MESZ schrieb Joshua Friedman : >I have tried pymprog and while 0-1 integer programs and linear programs >seems to work great, there might be a bug in integer programs. Is there >a >good interface for python I can use to teach my students. I also need >to >use sensitivity reports. >Thanks https://en.wikibooks.org/wiki/GLPK/Python has a list of known Python wrappers for GLPK. Best regards Heinrich
[Fwd: Re: Adding if/then/else statement to GMPL]
Forwarded Message From: Jeffrey Kantor To: Andrew Makhorin Cc: "Meketon, Marc" , Domingo Alvarez Duarte , help-glpk@gnu.org Subject: Re: Adding if/then/else statement to GMPL Date: Mon, 24 Aug 2020 12:38:42 -0500 > Respectfully, and I very much appreciate the careful design of GMPL > and its utility for creating ‘beautiful’ models, I have to disagree. > What is being proposed, I think, is not a general purpose programming > language, but rather extensions to GMPL making it more suitable to > expressing well accepted models for important OR applications. Stock > cutting is one example, but there are many others. > > GMPL is very well suited to documenting models and applications, > especially for teaching and education. They’re short, to the point, > and above all, largely self-documenting. Extending the language should > and could maintain these attributes. zWithout these extensions, I fear > that GMPL will whither on the vine in favor of precisely what you > describe … modeling tools embedded in higher level languages like > Python and Julia. > > My hope is the GMPL v2 would, like GMPL v1, something that, once > created, stays fixed for decades. This is the advantage of a reference > language for representing models, a role for which GMPL has been > successful. Models embedded in Python, Julia, etc, typically require > additional maintanece as the languages and extensive libraries evolve. > With GMPL one doesn’t have to worry about that. > > > > On Aug 24, 2020, at 12:17 PM, Andrew Makhorin wrote: > > > > On Mon, 2020-08-24 at 14:00 +, Meketon, Marc wrote: > > > I've always felt that GMPL needed if-then-else, for-loops, 'let' > > > statements and the ability to re-solve to be a true modeling > > > language. And Andrew has always disagreed. > > > > > > Many of the models that I create ultimately are 'iterative' where > > > I > > > need to take the results of one model and use it to setup another > > > model. To me, that is also modeling. GMPL doesn't have it. > > > > > > So often, I use GMPL for an initial model - it is a wonderful > > > language, and I find it faster to code than alternatives. But > > > then > > > when I 'get it right' I have to re-code it in PYOMO or PULP or > > > write > > > directly to an 'lp' file within a Python or C# or other language > > > script. > > > > > > Having the ability to run, adjust variables, add/take away > > > constraints, re-run would be extremely useful, and make GMPL more > > > of a > > > one-stop modeling language. > > > > > > > I agree that programming features like "goto" (as well as its > > structured > > versions) sometimes are necessary, but in my opinion it should be > > another language. Probably something like MPL (Math Programming > > Language) developed by G.Dantzig in 70's is what you would like to > > have; > > see https://dl.acm.org/doi/10.1145/800184.810495 . > > The initial design of AMPL, which GNU MathProg is based on, is not > > suitable to make AMPL a full-featured programming language, and in > > my > > opinion all further additions just broke the design being > > incompatible > > with it. > > > > On the other hand, developing and implementing yet another (even > > domain-specific) programming language is not a good idea. I think > > that > > modeling features might be built *over* an appropriate programming > > language. A good example of such approach is the GNU LilyPond (a > > music > > engraving program; see https://lilypond.org/ ), where the domain- > > specific part is built over the Scheme programming language (a > > dialect > > of Lisp): in normal circumstances the user writes all things with > > domain-specific constructions, but if something unusual is needed, > > he/she may write things on a lower level directly in Scheme. > > > > > > Andrew Makhorin > >
best Python interface for GLPK
I have tried pymprog and while 0-1 integer programs and linear programs seems to work great, there might be a bug in integer programs. Is there a good interface for python I can use to teach my students. I also need to use sensitivity reports. Thanks -- Joshua Friedman PhD crownea...@gmail.com http://www.math.sunysb.edu/~joshua
Re: Adding if/then/else statement to GMPL
On Mon, 2020-08-24 at 14:00 +, Meketon, Marc wrote: > I've always felt that GMPL needed if-then-else, for-loops, 'let' > statements and the ability to re-solve to be a true modeling > language. And Andrew has always disagreed. > > Many of the models that I create ultimately are 'iterative' where I > need to take the results of one model and use it to setup another > model. To me, that is also modeling. GMPL doesn't have it. > > So often, I use GMPL for an initial model - it is a wonderful > language, and I find it faster to code than alternatives. But then > when I 'get it right' I have to re-code it in PYOMO or PULP or write > directly to an 'lp' file within a Python or C# or other language > script. > > Having the ability to run, adjust variables, add/take away > constraints, re-run would be extremely useful, and make GMPL more of a > one-stop modeling language. > I agree that programming features like "goto" (as well as its structured versions) sometimes are necessary, but in my opinion it should be another language. Probably something like MPL (Math Programming Language) developed by G.Dantzig in 70's is what you would like to have; see https://dl.acm.org/doi/10.1145/800184.810495 . The initial design of AMPL, which GNU MathProg is based on, is not suitable to make AMPL a full-featured programming language, and in my opinion all further additions just broke the design being incompatible with it. On the other hand, developing and implementing yet another (even domain-specific) programming language is not a good idea. I think that modeling features might be built *over* an appropriate programming language. A good example of such approach is the GNU LilyPond (a music engraving program; see https://lilypond.org/ ), where the domain- specific part is built over the Scheme programming language (a dialect of Lisp): in normal circumstances the user writes all things with domain-specific constructions, but if something unusual is needed, he/she may write things on a lower level directly in Scheme. Andrew Makhorin
[Fwd: Re: Adding if/then/else statement to GMPL]
Forwarded Message From: Jeffrey Kantor To: "Meketon, Marc" Cc: Andrew Makhorin , Domingo Alvarez Duarte , help-glpk@gnu.org Subject: Re: Adding if/then/else statement to GMPL Date: Mon, 24 Aug 2020 09:54:33 -0500 > This would be another vote for extending GMPL to include features to > support the iterative use of LP’s. As is stands, GMPL is a sweet > little modeling tool … a well-crafted application is small work of art > that is generally clear and unambiguous. One mark fo a good model is > the ability to go back years later and instantly recall the logic > behind the model. > > There are so many more applications where iteration is a natural part > of the modeling. Stocking cutting, for example. Stochastic > programming. With these features, GMPL could continue to be a useful > tool for developing and documenting models and MILP applications. > Without these features, tools like PULP and Pyomo become the lingua > franca of the field. > > > On Aug 24, 2020, at 9:00 AM, Meketon, Marc via Users list for GLPK > > (GNU Linear Programming Kit) wrote: > > > > I've always felt that GMPL needed if-then-else, for-loops, 'let' > > statements and the ability to re-solve to be a true modeling > > language. And Andrew has always disagreed. > > > > Many of the models that I create ultimately are 'iterative' where I > > need to take the results of one model and use it to setup another > > model. To me, that is also modeling. GMPL doesn't have it. > > > > So often, I use GMPL for an initial model - it is a wonderful > > language, and I find it faster to code than alternatives. But then > > when I 'get it right' I have to re-code it in PYOMO or PULP or write > > directly to an 'lp' file within a Python or C# or other language > > script. > > > > Having the ability to run, adjust variables, add/take away > > constraints, re-run would be extremely useful, and make GMPL more of > > a one-stop modeling language. > > > > -Original Message- > > From: Help-glpk > org> On Behalf Of Andrew Makhorin > > Sent: Sunday, August 23, 2020 2:56 PM > > To: Domingo Alvarez Duarte ; help-glpk@gnu.org > > Subject: Re: Adding if/then/else statement to GMPL > > > > On Sun, 2020-08-23 at 15:36 +0200, Domingo Alvarez Duarte wrote: > > > Hello ! > > > > > > Also I've added the break/continue statements here > > > https://github.com/mingodad/GLPK/commit/9d70a37b16bd377722eeb3880f > > > cf86 > > > bb3b812118 > > > > > > > > > Again any comment/suggestion is welcome ! > > > > > > Cheers ! > > > > > > > > > > > > > Please note that GNU MathProg is a *modeling* language; it is not a > > general-purpose programming language. If you need to produce a non- > > trivial solution report (since all such-like statements are allowed > > only on the post-solving stage), it would be more practical to write > > the solution to a temporary file and then process it with a separate > > program. > > > > > > > > > > > > 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. > >
Re: Adding if/then/else statement to GMPL
Hello Heinrich !
That example was a silly one only to do a minimal check that the add
if/then/else was working (properly?).
My implementation doesn't seem to need much code and allow a bit better
expressiveness to GMPL.
Another example from examples/pentomino.mod:
Before:
for{i in 1..m}
{ for{j in 1..n}
{ for{0..0: (i,j) in R}
{ for{(c,ii,jj) in S: (i-ii,j-jj) in D[c] and x[c,ii,jj]}
printf" %s", substr(c,1,1);
}
for{0..0: (i,j) not in R}
printf" .";
}
printf"\n";
}
After:
for{i in M}
{ for{j in N}
{ if(i,j) in R then
{ for{(c,ii,jj) in S: (i-ii,j-jj) in D[c] and x[c,ii,jj]}
printf" %s", substr(c,1,1);
}
else
printf" .";
}
printf"\n";
}
Cheers !
On 24/8/20 16:59, Heinrich Schuchardt wrote:
On 24.08.20 16:33, Domingo Alvarez Duarte wrote:
Hello Meketon !
Could you share your view of how it would be expressed (an ideal model
sample) ?
If you want to talk about it, maybe I'll be interested in implement it !
Can you share a collection of models data to be used as base for the
test/implementation ?
Dear Domingo,
I do not yet understand what was you weren't able to express with the
current syntax.
Instead of
if length(p) == 3 then display "true 3"; else display "false 3";
if length(p) == 5 then display "true 5"; else display "false 5";
you can write:
param p,symbolic := "dad";
display if length(p) == 3 then "true 3" else "false 3";
display if length(p) == 5 then "true 5" else "false 5";
solve;
end;
Best regards
Heinrich
RE: Adding if/then/else statement to GMPL
Since GMPL is a subset of AMPL, I would begin by looking at: https://ampl.com/BOOK/CHAPTERS/16-script.pdf As far as examples, the classic 'cutting stock' problem is a good one. The AMPL site has two different iterative approaches: https://ampl.com/BOOK/EXAMPLES/EXAMPLES2/cut.mod https://ampl.com/BOOK/EXAMPLES/EXAMPLES2/cut.run and https://ampl.com/BOOK/EXAMPLES/EXAMPLES2/cut2.mod https://ampl.com/BOOK/EXAMPLES/EXAMPLES2/cut2.run and the data file is at: https://ampl.com/BOOK/EXAMPLES/EXAMPLES2/cut.dat -Original Message- From: Domingo Alvarez Duarte Sent: Monday, August 24, 2020 10:34 AM To: Meketon, Marc ; Andrew Makhorin ; help-glpk@gnu.org Subject: Re: Adding if/then/else statement to GMPL Hello Meketon ! Could you share your view of how it would be expressed (an ideal model sample) ? If you want to talk about it, maybe I'll be interested in implement it ! Can you share a collection of models data to be used as base for the test/implementation ? Cheers ! On 24/8/20 16:00, Meketon, Marc wrote: > I've always felt that GMPL needed if-then-else, for-loops, 'let' statements > and the ability to re-solve to be a true modeling language. And Andrew has > always disagreed. > > Many of the models that I create ultimately are 'iterative' where I need to > take the results of one model and use it to setup another model. To me, that > is also modeling. GMPL doesn't have it. > > So often, I use GMPL for an initial model - it is a wonderful language, and I > find it faster to code than alternatives. But then when I 'get it right' I > have to re-code it in PYOMO or PULP or write directly to an 'lp' file within > a Python or C# or other language script. > > Having the ability to run, adjust variables, add/take away constraints, > re-run would be extremely useful, and make GMPL more of a one-stop modeling > language. > > -Original Message- > From: Help-glpk > On Behalf Of > Andrew Makhorin > Sent: Sunday, August 23, 2020 2:56 PM > To: Domingo Alvarez Duarte ; help-glpk@gnu.org > Subject: Re: Adding if/then/else statement to GMPL > > On Sun, 2020-08-23 at 15:36 +0200, Domingo Alvarez Duarte wrote: >> Hello ! >> >> Also I've added the break/continue statements here >> https://github.com/mingodad/GLPK/commit/9d70a37b16bd377722eeb3880fcf8 >> 6 >> bb3b812118 >> >> >> Again any comment/suggestion is welcome ! >> >> Cheers ! >> >> >> > Please note that GNU MathProg is a *modeling* language; it is not a > general-purpose programming language. If you need to produce a non-trivial > solution report (since all such-like statements are allowed only on the > post-solving stage), it would be more practical to write the solution to a > temporary file and then process it with a separate program. > > > > > > 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. 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.
Re: Adding if/then/else statement to GMPL
On 24.08.20 16:33, Domingo Alvarez Duarte wrote: > Hello Meketon ! > > Could you share your view of how it would be expressed (an ideal model > sample) ? > > If you want to talk about it, maybe I'll be interested in implement it ! > > Can you share a collection of models data to be used as base for the > test/implementation ? Dear Domingo, I do not yet understand what was you weren't able to express with the current syntax. Instead of if length(p) == 3 then display "true 3"; else display "false 3"; if length(p) == 5 then display "true 5"; else display "false 5"; you can write: param p,symbolic := "dad"; display if length(p) == 3 then "true 3" else "false 3"; display if length(p) == 5 then "true 5" else "false 5"; solve; end; Best regards Heinrich
Re: Adding if/then/else statement to GMPL
Hello Meketon ! Could you share your view of how it would be expressed (an ideal model sample) ? If you want to talk about it, maybe I'll be interested in implement it ! Can you share a collection of models data to be used as base for the test/implementation ? Cheers ! On 24/8/20 16:00, Meketon, Marc wrote: I've always felt that GMPL needed if-then-else, for-loops, 'let' statements and the ability to re-solve to be a true modeling language. And Andrew has always disagreed. Many of the models that I create ultimately are 'iterative' where I need to take the results of one model and use it to setup another model. To me, that is also modeling. GMPL doesn't have it. So often, I use GMPL for an initial model - it is a wonderful language, and I find it faster to code than alternatives. But then when I 'get it right' I have to re-code it in PYOMO or PULP or write directly to an 'lp' file within a Python or C# or other language script. Having the ability to run, adjust variables, add/take away constraints, re-run would be extremely useful, and make GMPL more of a one-stop modeling language. -Original Message- From: Help-glpk On Behalf Of Andrew Makhorin Sent: Sunday, August 23, 2020 2:56 PM To: Domingo Alvarez Duarte ; help-glpk@gnu.org Subject: Re: Adding if/then/else statement to GMPL On Sun, 2020-08-23 at 15:36 +0200, Domingo Alvarez Duarte wrote: Hello ! Also I've added the break/continue statements here https://github.com/mingodad/GLPK/commit/9d70a37b16bd377722eeb3880fcf86 bb3b812118 Again any comment/suggestion is welcome ! Cheers ! Please note that GNU MathProg is a *modeling* language; it is not a general-purpose programming language. If you need to produce a non-trivial solution report (since all such-like statements are allowed only on the post-solving stage), it would be more practical to write the solution to a temporary file and then process it with a separate program. 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.
RE: Adding if/then/else statement to GMPL
I've always felt that GMPL needed if-then-else, for-loops, 'let' statements and the ability to re-solve to be a true modeling language. And Andrew has always disagreed. Many of the models that I create ultimately are 'iterative' where I need to take the results of one model and use it to setup another model. To me, that is also modeling. GMPL doesn't have it. So often, I use GMPL for an initial model - it is a wonderful language, and I find it faster to code than alternatives. But then when I 'get it right' I have to re-code it in PYOMO or PULP or write directly to an 'lp' file within a Python or C# or other language script. Having the ability to run, adjust variables, add/take away constraints, re-run would be extremely useful, and make GMPL more of a one-stop modeling language. -Original Message- From: Help-glpk On Behalf Of Andrew Makhorin Sent: Sunday, August 23, 2020 2:56 PM To: Domingo Alvarez Duarte ; help-glpk@gnu.org Subject: Re: Adding if/then/else statement to GMPL On Sun, 2020-08-23 at 15:36 +0200, Domingo Alvarez Duarte wrote: > Hello ! > > Also I've added the break/continue statements here > https://github.com/mingodad/GLPK/commit/9d70a37b16bd377722eeb3880fcf86 > bb3b812118 > > > Again any comment/suggestion is welcome ! > > Cheers ! > > > Please note that GNU MathProg is a *modeling* language; it is not a general-purpose programming language. If you need to produce a non-trivial solution report (since all such-like statements are allowed only on the post-solving stage), it would be more practical to write the solution to a temporary file and then process it with a separate program. 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.
