[Os-project-managers] OSAmplClient.cpp

[R. Kipp Martin]

Hi Gus:

>
> Could be dicey. One of the messages below is "name/value pair is not
> enough". I can see a referee turn this around and use it against us:
> "How do you know that name/value/type/category:subcategory will be
> enough in all instances?" I am not sure how I would respond to that
> other than "well, it's better than name/value pair". But I agree; I was
> definitely thinking about the paper when I wrote this stuff.

No sure about this.


>
> I am toying with all sorts of ways to move forward, both on the paper
> and on the .nl files. Too bad that there is no actual description of the
> .nl file format anywhere. I asked Dave about this a few years ago and he
> said he never got around to it. Agreed it was a good idea. Probably

Interesting! David Gay not writing a description of nl files is a 
beautiful example of why XML and Schemas are great technology. The 
schema is the standard, in addition, the schema also provides the 
"documentation." When you make a schema you are in effect, creating the 
documentation at the same time. Not only that but there already exists 
software which can validate the file.

Cheers


> enough of it is contained in the "Hooking" document and the file
> readme.suf to make a decent go of it, perhaps even to write a flex/bison
> parser, but I am not particularly anxious to go down that path...
>
> Next thing to do is look at Ipopt --- after I pick up Yael's cousin from
> the airport.
>
> Cheers
>
> gus
>
>>> I believe this is a reasonable dichotomy. The point is that not all AMPL
>>> options get put into the .nl file. In fact, only things that are indexed
>>> over variables, constraints or objectives show up in the .nl file; all
>>> other options are given in the solverName_options variable. AMPL is
>>> actually quite agnostic of the solver options, but it makes the
>>> assumption that all options are either keywords (prefixed with a minus
>>> sign) or else a name/value pair. This won't do for us --- it is unsafe
>>> to try to infer the type of an option from its current value, and there
>>> is no way to figure out the category. So it is best to stay clear of
>>> those scalar-valued options.
>>>
>>> But the vector-valued options in the .nl file should be used. Most of
>>> those are derived from suffixes of variables and slacks, but the nasty
>>> thing is that they include user-defined suffixes (which the user may
>>> have set up just for his own entertainment, or because the solver he
>>> uses has a fancy new gadget), and I do not see at this point how ASL
>>> will let me explore what suffixes the .nl file actually contains. This
>>> was the content of the email to David Gay.
>>>
>>> I since found a document in the ASL download that describes suffixes,
>>> but only in situations where you know what you are looking for. Say, we
>>> hook up to a new solver, DevelopersSolver, which has some new gizmo that
>>> needs input indexed over the variables. In AMPL you can set this up by
>>> defining a suffix 'gizmo' and supplying values for x[0].gizmo,
>>> x[1].gizmo, etc. AMPL knows what suffixes have been set and transfers
>>> this to the .nl file, but we don't know about it unless the developer
>>> tells us. (And in particular we can never be sure if a suffix 'gus' is
>>> there only for the amusement of a weirdo user, or if the DeveloperSolver
>>> actually looks for it. So we'd _have_ to pass it on in the hopes that it
>>> makes sense down the line.)
>>>
>>> If there were a way to detect the presence of gizmo values in the .nl
>>> file, we could grab the stuff in the same way we can grab initial values
>>> and basis information, and then we could transfer it properly (in
>>> <variables> <other>)
>
>
>


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
--