Separate latex representation and python variable name?

[bqpd]

 In: W_rbar = Monomial('\bar{W_r}') 
     print W_rbar
Out: Monomial(\bar{W_r})

Should this be allowed?

[whoburg]

Brainstorming for use within an organization

Possible string representations of the same variable:

• latex representation
• local name in a model, e.g. eta -- related to Variable namespaces and naming conventions #66
• global name in a GP, e.g. eta_motor_outboardflap
• python variable name (restricted! no spaces, slashes, etc)

[whoburg]

I know this might break some current functionality, but it's my opinion that any string should be a valid variable name. So, the following test (which currently fails), should work:

# variable names not compatible with python namespaces
crazy_varstr = 'what the !!!/$\**?'
m = Monomial({'x': 1, crazy_varstr: .5}, 25)
self.assertTrue(crazy_varstr in m.exp)

If we wanted to take this view to the extreme (which I'm not sure I support) we could allow variable names to be any valid dictionary key (e.g. m = Monomial({(1, 'foo'): 2})).

[bqpd]

I'm sure I don't support that extreme. Because then we'd need a third representation of the name, to match the two (python var and latex string) that we already have.

Note that latex representations might also have local / global names.

[whoburg]

Why not make the representation any string, and compute the latex string from the string representation? We already have the lookup table for e.g. theta, nu, etc, so we're somewhat doing this already, right?

[bqpd]

What do you mean by "compute the latex string"? If you mean that the "representation" of a variable should be equivalent to its latex string (i.e., 'computing' is just printing), I agree. On the other hand, if computing involves some translation step, that seems unnecessary.

[whoburg]

I was imagining that there could be an (optional) method (possibly client-defined code) that would return latex as a function of the variable's string representation (the key in the exp dict).

The simple version, which I agree should be the default in gpkit, is that the two are equivalent. But one could imagine all sorts of fancy schemes, e.g. latexstr('theta') = '\theta', or latexstr('W_bar') = '\bar{W}', or latexstr('my funny variable name') = '\textnormal{my funny variable name}'.

[bqpd]

1. Is the variable's string representation the same as its key? As noted at 0a9d9d8, I'm prone to require keys to be valid python variable names.
2. Does this need to be a function? Why not just a third part to a variable's description (along with units and text string) that it carries around with it?

[whoburg]

Good discussion.

1. I guess I'm converging on thinking that the key should be any valid dictionary key, and should uniquely map to all other representations of the variable (possibly through client-defined code). the benefit would be that we could use information-rich strings (such as the latex) as keys. The drawback would be eliminating the valid python variable name requirement/feature.
2. I think I'm converging on this because of a concern about taking on the responsibility to store all kinds of variable representations inside our objects. I guess I'm proposing solving that by requiring a single representation (the dict key). And I think it's important that we be able to use a latex string as one possible representation, which is what's leading me to propose abandoning the python variable name requirement.

For dict_monify_up, my proposal would be that trying to update the globals dict with non-valid python variable names would just raise an exception. Then users who want to restrict themselves to valid python variable names can still enjoy the current functionality.

[bqpd]

Sounds reasonable to me.

[bqpd]

Discussion settled by #72.