[WIP] experimental way to access expression methods #430
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.
This creates an
Expression
class that wrapsSymbolicRegression.Node
. This would make it easier to access various internal methods ofSymbolicRegression
.However, this is very experimental and I'm not sure what the best way forward is. There are a few options:
PySRRegressor
. Cleaner because we don't need the user to passmodel
andvariable_names
manually. However I'm worried the number of methods toPySRRegressor
could explode.....Node
. Then, expect the user to callSymbolicRegression.<method>
themselves, usingmodel.sr_options_
when needed.I think (3) would make the maintenance job the easiest was we wouldn't have to write a Python equivalent for everything..... However, one downside is that the printing functionality for manually-created expressions does not seem to use
variable_names
. Maybe for that we need to setdefine_helper_functions=True
when creating theOptions
.Fixes #339 and probably a few other issues which want an easier way to access backend internals.
Current version is an attempt at (1):