Skip to content

New StringVariable - #110

Open
eduardo-ocampo wants to merge 19 commits into
devfrom
56-create-a-string-variable-type
Open

eduardo-ocampo wants to merge 19 commits into
devfrom
56-create-a-string-variable-type

Conversation

@eduardo-ocampo

@eduardo-ocampo eduardo-ocampo commented Sep 16, 2026 •

Copy link
Copy Markdown
Collaborator

Adds a new StringVariable type for carrying string values through a problem setup. Closes #56

Because strings are not something an optimizer can act on, StringVariable types are supported as input or an output only and always treated as fixed with an OptProblem.

Changes:

  • New StringVariable inherited from FloatVariable and modeled after CatgoricalVariable
  • Added StringVariable to Variable union. As well as being importable via standard_evaluator.StringVariable
  • Created OptProblem validation for StringVariable. Errors if StringVariable is used as an objective or constraint.
  • Modified build_maps utility to treat variables ( StringVariable) with no numeric bounds as fixed.
  • For StringVariable, calculate_default method does not overwrite an existing default since it has no bounds to derive from. StringVariable.calculate_default is 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 being None

Testing

  • Adds tests in tests\test_problem.py to construct and validate StringVariable. Additional tested created to test StringVariable interaction with OptProblem
  • New test tests\test_string_variable_evaluation.py asserts wrapped evaluator matches a direct call and that the types are preserved.

@eduardo-ocampo eduardo-ocampo self-assigned this Sep 16, 2026
@eduardo-ocampo eduardo-ocampo linked an issue Sep 16, 2026 that may be closed by this pull request
@eduardo-ocampo eduardo-ocampo changed the title Add developer header New StringVariable Sep 22, 2026

@jmgablon jmgablon left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/standard_evaluator/problem.py Outdated
# 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:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes were made in recent commits to allow StringVariables as responses.

Comment thread tests/test_problem.py
StringVariable(name="bad name")

# An empty name is allowed, consistent with the other variable types.
assert StringVariable(name="").name == ""

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should allow an empty name. Let's examine this in a different MR.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create a string variable type

2 participants