Well said.
Sent from my mobile
On Aug 24, 2020, at 1:39 PM, Jeffrey Kantor <jeff.kantor@gmail.com> 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 < mao@gnu.org> wrote:
On
Mon, 2020-08-24 at 14:00 +0000, 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.
|