Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Close #134
Currently, when constructing Decapodes, tangent variables are always renamed as the variable they depend on appended with a dot.
E.g.
D == \partial\_t(C)
creates a Decapode with two variables namedC\dot
andC
.This strategy was chosen by default since users sometimes only describe TVars in terms of their relation to other quantities. E.g. in
\partial\_t(Foo) == Bar(Buzz)
, the quantity\partial\_t(Foo)
is never given a human-legible name. So defaulting toFoo\dot
is appropriate.This is, of course, always fine from a compilation aspect, since the generated program is name-agnostic.
But, this can seriously impact usability. If a user has created a Decapode, and has given a TVar a human-readable name, then they expect to be able to refer to the TVar by that when trying to compose with it.
It should be noted that renaming variables using the append-dot method is an example of where we can make physical systems more legible through analysis of a Decapode. In other words, we can perform some rewriting to tell the user that a variable is a first, second, or higher-order derivative. Users in practice essentially must traverse the TVar table to glean this information themselves. If done elegantly, this exemplifies the automation of physical intuition that we often aim for. If done inelegantly - by renaming too aggressively - we confuse the reader when they try to compose Decapodes.
So, in this PR, we default to using human-legible variable names when provided, and only rename with dots when no name is available. We also offer a function that aggressively performs renaming that the user can call on-demand.