Open ashiklom opened 4 years ago
looks good to me. I think we'd just want a concrete list of the allowable variable_types. I think I'd add: driver, parameter, random_effect, observation, observation_error, process_error (obviously we'd update this list if we update the uncertainty list), and diagnostic (since @rqthomas mentioned this was useful in his files). Two (related) questions I'd have:
<attributeName>
listing within the <assimilation>
additionalMetadata to allow users to ID which variables are being updated, with the understanding that those names would have to match something in the <attributeList>
.One case to consider is a flux (so it isn't a state) that is assimilated (so it isn't a diagnostic). This would fall through the classification cracks. Also, is there an easier regex to parse. I just use a colon ":" to separate the variable_type from the actual long name. However, what you present is cleaner to read and if the average user isn't going to have to right complex regex statements then I am fine with your proposal.
I think we'd just want a concrete list of the allowable variable_types.
Yup, this can be implemented as a factor, and we can throw errors if the result has any NA
s.
do we need to have an initial_condition type and a statevariable type or are they always one and the same?
I'm inclined to think they're the same, but I'm open to counterexamples.
Is it possible for a single variable to have more than one type?
I think we should define our types to avoid this if at all possible (i.e., if this is possible, then we haven't defined our types well). From an implementation standpoint, there's no reason we couldn't implement multiple types with either [type1][type2]{description}
or [type1|type2]{description}
(or similar), but everything is simpler (conceptually and for implementation) if a variable can only have one type.
One case to consider is a flux (so it isn't a state) that is assimilated (so it isn't a diagnostic)
Even though it breaks ontogenies, I'd probably be OK calling that a "state".
Also, is there an easier regex to parse.
I picked this regex specifically for its parseability. As long as we define just a few simple rules— the [type]
has to come first, no []
characters inside the type, and no characters after the description, the following should be pretty robust to just about any input. Note that the ?
in the first .*?
specifies a non-greedy regex, so it will find the shortest string before a ]
(rather than the default, which is greedy and will find the longest match; that could slurp up []
in the description). I also added a few *
to make this robust to whitespace.
"^ *\\[(.*?)\\] *\\{(.*)\\} *$"
if the average user isn't going to have to right complex regex statements
Yeah, definitely not. The regex will be hard-coded in a parse_variable()
or similar function in this package or elsewhere.
Per the discussion today, were we looking for something like this? The general idea is that
attributeDefinition
has the format[variable_type]{Variable definition...}
.Created on 2020-09-15 by the reprex package (v0.3.0)