-
Notifications
You must be signed in to change notification settings - Fork 9
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
sinkhorn_barycenter refactor #110
Conversation
Sorry for not replying earlier, I just came back from vacation 🙂
If this is possible, it could be a good way to reduce code and ensure that the implementations are consistent. However, I think this can be left for a future PR. |
Pull Request Test Coverage Report for Build 1161321360
💛 - Coveralls |
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
==========================================
+ Coverage 96.25% 96.71% +0.45%
==========================================
Files 11 12 +1
Lines 561 608 +47
==========================================
+ Hits 540 588 +48
+ Misses 21 20 -1
Continue to review full report at Codecov.
|
Hi all,
I've done a quick refactor of
sinkhorn_barycenter
to now conform to conventions introduced in #100 (which I'm sorry I missed at the time due to moving), reusing code fromsinkhorn.jl
andsinkhorn_gibbs.jl
where possible.Problem parameters are specified in
SinkhornBarycenterSolver
, and the standard scaling algorithm corresponds to settingalg = SinkhornBarycenterGibbs()
I've had to define
SinkhornBarycenterGibbsCache
separately because in order to do the convergence checks, I need to keep track of the barycenter at each iteration, nameda
in the code. For the convergence check I use the existingSinkhornConvergenceCache
struct.Let me know if there's anything further that can be cleaned up in the code.
One thing I will note here is that quite a few parts of
solve!
can be reused betweenSinkhornGibbs
andSinkhornBarycenterGibbs
-- essentially the differences come down to the update steps and the arguments passed to the convergence check. One solution here could be to wrap the update steps into algorithm-specific calls via multiple dispatch. I haven't attempted this yet (maybe a future PR?) but I'd be keen to hear your thoughts.