-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate latex representation and python variable name? #68
Comments
Brainstorming for use within an organization Possible string representations of the same variable:
|
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:
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. |
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. |
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? |
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. |
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. |
|
Good discussion.
For |
Sounds reasonable to me. |
Discussion settled by #72. |
Should this be allowed?
The text was updated successfully, but these errors were encountered: