Refactor Constant representation #79
Conversation
Codecov Report
@@ Coverage Diff @@
## master #79 +/- ##
==========================================
- Coverage 79.46% 79.23% -0.24%
==========================================
Files 11 11
Lines 409 390 -19
==========================================
- Hits 325 309 -16
+ Misses 84 81 -3
Continue to review full report at Codecov.
|
| @@ -5,7 +5,7 @@ function lower_varname(var::Variable, naming_scheme; lower=false) | |||
| lower_varname(var.name, D.x, order, var.subtype, naming_scheme) | |||
| end | |||
| function lower_varname(sym::Symbol, idv, order::Int, subtype::Symbol, naming_scheme) | |||
| order == 0 && return Variable(sym, subtype) | |||
| order == 0 && return Variable(sym, subtype=subtype) | |||
There was a problem hiding this comment.
What a subtle bug!
There was a problem hiding this comment.
Yep - I also changed this function afterwards, to make the goal more explicit.
|
How does this effect the Terms usage? In terms, would a Constant be a separate entity as well? |
|
Reasoning about algebraic expressions as syntax trees, Terms deals with the "branches", leaving the "leaves" to the user. My plan is to strategically swap out the internals of This particular refactor is part of a general move towards structuring our objects in a way that more naturally describes the data stored. Since the concept of a numerical constant seems fairly disconnected from the concept of a variable/parameter, splitting it off makes a handful of undesired states unrepresentable. By doing this, I eliminated at least one bug immediately which was previously able to sneak by. |
No description provided.