Refactor/Fix: WassersteinSolver constructor now throws TypeError when an unrecognized argument is given #579

selmanozleyen · 2024-09-23T13:50:36Z

hi,

A user can give an argument by typo or any other misunderstanding and the solver class would work without them noticing. To prevent such cases I made some modifications. I also added tests that asserts that the raises are thrown properly.

Note: I am not sure about why the linting fails, it tox -e lint-code passes locally for me. Note: I also modified the caching in CI's because it didn't work on my pr for some reason

Related: theislab/moscot#748

ping: @MUCDK

codecov · 2024-09-23T15:46:58Z

Codecov Report

Attention: Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 87.81%. Comparing base (aa33bd9) to head (88bde47).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/ott/solvers/was_solver.py	57.14%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #579      +/-   ##
==========================================
- Coverage   87.83%   87.81%   -0.03%     
==========================================
  Files          73       73              
  Lines        7826     7845      +19     
  Branches     1127     1133       +6     
==========================================
+ Hits         6874     6889      +15     
- Misses        799      801       +2     
- Partials      153      155       +2

Files with missing lines	Coverage Δ
src/ott/solvers/was_solver.py	`79.59% <57.14%> (-3.75%)`	⬇️

... and 4 files with indirect coverage changes

marcocuturi · 2024-09-24T11:43:19Z

thanks @selmanozleyen for the PR! i will defer to @michalk8 on this, but it feels that if we implement this for this particular solver, we would need to implement it for all solvers, no? What was the use case that revealed the problem?

selmanozleyen · 2024-09-24T12:14:55Z

For linear solvers there is no need as their base class Sinkhorn doesn't take kwargs. Since WassersteinSolver now handles unrecognized kwargs, all it's child classes will also handle it (since all child classes pass remaining kwargs to super()__init__()).

In moscot we don't want to ignore any unrecognized arguments since there are many arguments, and with some typo etc. it can lead to some well hidden bugs.

Here is the PR for it:theislab/moscot#748

We use many (if not all) solvers in our case and from my tests this PR should be enough to cover the constructors for linear and quadratic solvers. I am not sure about other methods such as solve in ottjax though.

michalk8

@selmanozleyen in the comment above, I think we should rather explicitly pass the linear_ot_solver to WassersteinSolver instead.
Lmk if you prefer to do it or not. I can also take a look at it, as there might be many places in tests/ that need a change.

michalk8 · 2024-09-25T14:33:36Z

.github/workflows/lint.yml

@@ -33,8 +33,11 @@ jobs:
      if: ${{ matrix.lint-kind == 'code' }}
      with:
        path: ~/.cache/pre-commit
-        key: pre-commit-${{ env.pythonLocation }}-${{ hashFiles('**/.pre-commit-config.yaml') }}
-
+        key: pre-commit-${{ runner.os }}-python-${{ env.pythonLocation }}-${{ hashFiles('**/.pre-commit-config.yaml') }}


I don't think this is necessary, as the cache key will be search on the PR's target branch if it's not on the feature branch.

did this as a temporary solution as ci's failed. the reformatting was also because of ci for some reason. will undo this and the reformatting

michalk8 · 2024-09-25T14:37:50Z

src/ott/solvers/was_solver.py

@@ -11,6 +11,7 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+import inspect


In general, I think there's a slightly better solution rather than inspecting the signature of the linear solvers,
I'd rather make linear_ot_solver a required argument and remove the construction of the solver in __init__ altogether - this will require some changes, esp. in tests, in ott/solvers/quadratic/_solve.py, etc.

then this means we can also remove kwargs right? I'd also prefer this to inspect but didn't want to change the interface in case you had other plans.

michalk8 · 2024-09-25T14:38:14Z

tests/solvers/quadratic/fgw_test.py

@@ -60,7 +59,12 @@ def test_gradient_marginals_fgw_solver(self, jit: bool):

    def reg_gw(a: jnp.ndarray, b: jnp.ndarray, implicit: bool):
      prob = quadratic_problem.QuadraticProblem(
-          geom_x, geom_y, geom_xy, fused_penalty=self.fused_penalty, a=a, b=b


Not sure why it was reformatted, but would prefer to undo.

tests/solvers/quadratic/fgw_test.py

This reverts commit bd6672c.

This reverts commit 73e6f54.

selmanozleyen · 2024-09-25T15:35:40Z

@michalk8 since the interface is going to change I think it would be better if you did it. I already resolved other pre-commit and formatting issues you mentioned

michalk8 · 2024-09-25T17:23:15Z

@michalk8 since the interface is going to change I think it would be better if you did it. I already resolved other pre-commit and formatting issues you mentioned

Ok, thanks! I will then close this PR and open tomorrow a new one.

selmanozleyen · 2024-10-01T13:24:06Z

hi @michalk8, just wanted to remind you on this. I think many test cases and stuff might have to change since the API also changes. So maybe I can help a bit

add checks for was solver

201a806

selmanozleyen mentioned this pull request Sep 23, 2024

Refactor/handle solve args theislab/moscot#748

Open

add tests for GWSolvers

73e6f54

maybe try to fix precommits?

bd6672c

marcocuturi requested a review from michalk8 September 24, 2024 11:43

marcocuturi added the enhancement New feature or request label Sep 24, 2024

michalk8 reviewed Sep 25, 2024

View reviewed changes

selmanozleyen added 3 commits September 25, 2024 17:25

Revert "maybe try to fix precommits?"

62b7582

This reverts commit bd6672c.

Revert "add tests for GWSolvers"

a3b30c8

This reverts commit 73e6f54.

formatting fix

88bde47

michalk8 closed this Sep 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor/Fix: WassersteinSolver constructor now throws TypeError when an unrecognized argument is given #579

Refactor/Fix: WassersteinSolver constructor now throws TypeError when an unrecognized argument is given #579

selmanozleyen commented Sep 23, 2024 •

edited

Loading

codecov bot commented Sep 23, 2024 •

edited

Loading

marcocuturi commented Sep 24, 2024

selmanozleyen commented Sep 24, 2024

michalk8 left a comment

michalk8 Sep 25, 2024

selmanozleyen Sep 25, 2024

michalk8 Sep 25, 2024

selmanozleyen Sep 25, 2024

michalk8 Sep 25, 2024

selmanozleyen Sep 25, 2024

selmanozleyen commented Sep 25, 2024

michalk8 commented Sep 25, 2024

selmanozleyen commented Oct 1, 2024

Refactor/Fix: WassersteinSolver constructor now throws TypeError when an unrecognized argument is given #579

Refactor/Fix: WassersteinSolver constructor now throws TypeError when an unrecognized argument is given #579

Conversation

selmanozleyen commented Sep 23, 2024 • edited Loading

codecov bot commented Sep 23, 2024 • edited Loading

Codecov Report

marcocuturi commented Sep 24, 2024

selmanozleyen commented Sep 24, 2024

michalk8 left a comment

Choose a reason for hiding this comment

michalk8 Sep 25, 2024

Choose a reason for hiding this comment

selmanozleyen Sep 25, 2024

Choose a reason for hiding this comment

michalk8 Sep 25, 2024

Choose a reason for hiding this comment

selmanozleyen Sep 25, 2024

Choose a reason for hiding this comment

michalk8 Sep 25, 2024

Choose a reason for hiding this comment

selmanozleyen Sep 25, 2024

Choose a reason for hiding this comment

selmanozleyen commented Sep 25, 2024

michalk8 commented Sep 25, 2024

selmanozleyen commented Oct 1, 2024

selmanozleyen commented Sep 23, 2024 •

edited

Loading

codecov bot commented Sep 23, 2024 •

edited

Loading