uniqueness of names

[mlubin]

On the call yesterday we discussed the issue about names for display purposes being different than names that one would want to use as unique lookup keys. I proposed allowing two different names per variable/constraint, a lookup name and a display name. Thinking about it more, this seems too complicated.

New proposal: We allow variables to have arbitrary non-unique names. On lookup, if there are two variables with the same name, we throw an error. That's all.

Pros:

• This is overall less breaking from 0.18
• Simple rules
• We already allow variables to have non-unique lookup names (the empty string), so this removes that exception

Cons:

• Authors of code that generates JuMP sub-models will have to decide if they prefer simple names that print well or names that are guaranteed to be unique and useful for lookup

@ccoffrin @jd-lara @IainNZ

jump-dev/JuMP.jl#1292

[ccoffrin]

To clarify, when you say "lookup names", you are talking about string based lookups, correct? In my software the variable refrence is what I will always use as the unique variable id.

Questions:

• if two variables have a string name, looking them up each by their variable refrence is still fine and does not generate an error?
• what are the implications of using non-unique names for https://github.com/odow/MathOptFormat.jl?

[mlubin]

you are talking about string based lookups, correct?

Yes, I mean lookup by string. More precisely, given a string, return the corresponding MOI.VariableIndex or JuMP.VariableRef.

if two variables have a string name, looking them up each by their variable refrence is still fine and does not generate an error?

Correct. The MOI.VariableIndex or JuMP.VariableRef is the ultimate identifier of the variable.

what are the implications of using non-unique names for https://github.com/odow/MathOptFormat.jl?

MOF or LP or MPS writers will have to generate unique names (this is already the case because we allow blank names). So the mapping from MOI model to the file formats won't be 1-1. OTOH, if you read an MOF/LP/MPS file into an MOI model you'll be able to look up the variables in the model using their names in the file.

[odow]

Authors of code that generates JuMP sub-models will have to decide if they prefer simple names that print well or names that are guaranteed to be unique and useful for lookup

I think we should encourage authors of JuMP extensions/submodels/etc to use anonymous variables with a meaningful print name, and provide an external way of accessing the variables if required. For example, they can bundle the references into the JuMP extension dictionary with model.ext[:power_models_jl]

[ccoffrin]

Based on clarifications, I think this is a good solution. The semantics are nearly the same as JuMP v0.18, which has been working quite well for our group thus far.

@odow, that is basically the convention that we are currently using.

[jd-lara]

I think the alternative works. For reference, this will create the following use cases:

• Use variable names and internal look-up for single models not meant to interact with other JuMP models. This can be done with JuMP.VariableRef. Variable names can be used for printing.
• Use anonymous variables when developing extension packages that build on top of JuMP like PowerSimulations and PowerModels. Exploit model.ext for those purposes or use an external dict with the references. This cases will require a variable name for printing.