New StringVariable - #110
eduardo-ocampo wants to merge 19 commits into
Conversation
…t I can push to git
…pace to check for StringVariable. Just like CategoricalVariable, StringVariable will cause these methods to short-circuit and return early
…ptProblem restrictions
…gVariable restrictions
jmgablon
left a comment
There was a problem hiding this comment.
Hi Eduardo,
this looks really good. I like that we use the existing capabilty to mark something as fixed to deal with string variables.
I have some comments, especially that a string variable can be an output.
We also need to make sure that string inputs or outputs are not overwritten when running an evaluation on a DataFrame. We should have a test that checks what happens with this:
import pandas as pd
df = pd.DataFrame({'input': ['one', 'two'], 'val': [3.4, 5.6]})
def my_example(df: pd.DataFrame) -> None:
df['out'] = df['input'] + df['val'].astype(str) # Creates a string output
df['val_out'] = df['val']*4.When we wrap this as an evaluator we want to get the same output as if we just call the function directly.
| # String variables are only supported as inputs (variables), not as | ||
| # responses. They are carried through the problem but never participate | ||
| # in the optimization itself. | ||
| for response in self.responses: |
There was a problem hiding this comment.
So we want to allow string variables as responses. Sometimes the output of an analysis can for example be a unique file name that points to a file that was generated by the analysis.
There was a problem hiding this comment.
Changes were made in recent commits to allow StringVariables as responses.
| StringVariable(name="bad name") | ||
|
|
||
| # An empty name is allowed, consistent with the other variable types. | ||
| assert StringVariable(name="").name == "" |
There was a problem hiding this comment.
I don't think we should allow an empty name. Let's examine this in a different MR.
…aluation pipeline
Adds a new
StringVariabletype for carrying string values through a problem setup. Closes #56Because strings are not something an optimizer can act on,
StringVariabletypes are supported as input or an output only and always treated as fixed with anOptProblem.Changes:
StringVariableinherited fromFloatVariableand modeled afterCatgoricalVariableStringVariabletoVariableunion. As well as being importable viastandard_evaluator.StringVariableOptProblemvalidation forStringVariable. Errors ifStringVariableis used as an objective or constraint.build_mapsutility to treat variables (StringVariable) with no numeric bounds as fixed.StringVariable,calculate_defaultmethod does not overwrite an existing default since it has no bounds to derive from.StringVariable.calculate_defaultis maintained to be consistent with the other variable types. Only fills with empty string if no default was set.abstract_evaluator.__call__'s fixed variable filter now guards against bounds beingNoneTesting
tests\test_problem.pyto construct and validateStringVariable. Additional tested created to testStringVariableinteraction withOptProblemtests\test_string_variable_evaluation.pyasserts wrapped evaluator matches a direct call and that the types are preserved.