Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

constraint_separation_index undocumented #452

Open
Jacob-Stevens-Haas opened this issue Jan 8, 2024 · 0 comments
Open

constraint_separation_index undocumented #452

Jacob-Stevens-Haas opened this issue Jan 8, 2024 · 0 comments
Labels
constraints Issue in how we currently apply constraints good first issue Good for newcomers Trapping Affects/implements Trapping SINDy

Comments

@Jacob-Stevens-Haas
Copy link
Collaborator

In ConstrainedSR3, the constraint_separation_index is an undocumented constructor argument. It's meaning is obvious (separating the equality from inequality constraints), but you have to read the code to know whether inequality or equality constraints are supposed to come first.

Discovered as I work to make TrappingSR3 a better subclass of ConstraintedSR3.

@Jacob-Stevens-Haas Jacob-Stevens-Haas added constraints Issue in how we currently apply constraints Trapping Affects/implements Trapping SINDy labels Jan 8, 2024
Jacob-Stevens-Haas added a commit that referenced this issue Jan 8, 2024
Previously, TrappingSR3 could only use constraints passed to it, and only then a
limited set of constraints.  It also didn't apply the trapping constraints
automatically, because constraints were required at __init__, and actually
shaping them requires knowledge about the number of features, typically not
known until fit (unless the user is a developer who knows how the feature
libraries work internally 😉)

WIP, Spawned issue #452
@Jacob-Stevens-Haas Jacob-Stevens-Haas added the good first issue Good for newcomers label Jan 9, 2024
jpcurbelo pushed a commit to jpcurbelo/pysindy_fork that referenced this issue Apr 30, 2024
Previously, TrappingSR3 could only use constraints passed to it, and only then a
limited set of constraints.  It also didn't apply the trapping constraints
automatically, because constraints were required at __init__, and actually
shaping them requires knowledge about the number of features, typically not
known until fit (unless the user is a developer who knows how the feature
libraries work internally 😉)

WIP, Spawned issue dynamicslab#452
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
constraints Issue in how we currently apply constraints good first issue Good for newcomers Trapping Affects/implements Trapping SINDy
Projects
None yet
Development

No branches or pull requests

1 participant