Trapping constraints #437
Closed
Trapping constraints #437
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is much faster than fitting the features, and can be used by trapping to replace some constraint index calculations. Also: Add docstring/type annotations Rename a variable so it doesn't shadow newly-imported name
There are several major differences from the version in example 8: * Coupled with PolynomialLibrary logic using PolynomialLibrary.powers_. Previously, this coupling was implicit and actually tied to the specific order in Example 8, not the order users would expect. * Instead of handling pre-flattened 2D array, constraints are built with target and feature axes separately, letting the caller handle formatting the constraints as "target" or "feature". This gives us flexibility to later clean up the constraint logic outside this function without needing to return here and removes the need for striding calculations like: n_tgts * (n_tgts + k - 1) + i + n_tgts * int(j * (2 * n_tgts - j - 3) / 2.0) Since constraints are built directly from the terms and exponents in the library, its much easier to read and debug the code. * Renamed "r" as "n_tgts", etc. Single-letter index variables are removed. When they occur in homogenous iterators, they are concatenated with what they're iterating (e.g. tgt_i, tgt_j) * Broke out the different kinds of constraints into helper functions to make it easier to test. This allows follow on work to auto-attach constraints to a problem.
(other than degree, which has to be 2)
|
@Jacob-Stevens-Haas or @MPeng5 Have you checked the updated trapping constraints are consistent with @MPeng5 's branch? Mai, it might be worth merging your branch into this pull request and then rewriting your examples to be consistent with the new syntax here. |
|
Oh damn, sorry, I thought I responded a while ago. TL; DR they should be consistent, but mine aren't int target/feature format - user has to flatten them to whichever format they want (there is code in the docstring for each type). I'll check when I get back from break. |
|
Note to self:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I wanted to share this work as a draft that adds
_make_constraints()from example 8 totrapping_sr3.py. All the differences are noted in the commit messages, but the big ones are:PolynomialLibrary.powers_.IMO this makes the logic a lot clearer, since the term in
n_tgts * (n_tgts + k - 1) + i + n_tgts * int(j * (2 * n_tgts - j - 3) / 2.0).Also a draft because I enabled too many
PolynomialLibraryoptions.include_interaction=Falsewould be incompatible with the trapping constraints IIUC. OTOH, connecting topowers_gives usinclude_bias=Trueandinteraction_only=Trueconstraints for free.