-
Notifications
You must be signed in to change notification settings - Fork 56
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
add method log_lbfgs - Riemannian logarithm using expm_frechet - #555
Conversation
…omitted in final release
Codecov Report
@@ Coverage Diff @@
## master #555 +/- ##
==========================================
- Coverage 98.94% 98.92% -0.03%
==========================================
Files 100 105 +5
Lines 9659 10473 +814
==========================================
+ Hits 9557 10360 +803
- Misses 102 113 +11
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
The first thing that is included, is, that your files have 0% code coverage, that you will have to check. Concerning the format, the CI reports a lot of changes necessary: But to fix that make sure Besides that – wow! 600 lines of code for one function. |
Thanks, I will give it another try - I see there is zero coverage for other
manifolds which I did not touch - eg SymmetricPositiveDefiniteFixedRank and
I am not sure where to start looking. The only test script I changed was
stiefel.jl. So I do need some help here. I reran the formatter.
The function itself is around 200 lines of code, including helpers (eg
vectorize/unvectorize of antisymmetric matrices). The 600 lines of code is
because I implemented a few functions that I believe should belong to
common Julia libraries - but I do not see them anywhere. They should be
useful outside of Manifolds.jl, and presumably could be included elsewhere.
* expm_frechet
* minimize_lbfgs (this is in Optim, but we talked about Optim being
expensive to include)
* I also included dot_exp, which gives us the velocity of the geodesic, and
included an alternative formula for the geodesic.
…On Wed, Nov 30, 2022 at 7:29 AM Ronny Bergmann ***@***.***> wrote:
The first thing that is included, is, that your files have 0% code
coverage, that you will have to check.
Concerning the format, the CI reports a lot of changes necessary:
https://github.com/JuliaManifolds/Manifolds.jl/actions/runs/3578455917/jobs/6018629102
But to fix that make sure
(a) to have Juliaformatter in its newest version
(b) to run the formatting from the base folder of Manifolds, e.g. as using
JuliaFormatter; format("."), because we have a few setups for our
formatting locally as well.
Besides that – wow! 600 lines of code for one function.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFP2KPQ4ELPRSLGSAGTWK5CD5ANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
The other manifolds will work as soon as formatting is fine. As soon as a first of the tests fails, no other is started and since we have groups of tests, some were not run (see those with a gray (!) upfront in the list of the checks, those were not run) so as soon as those do run, the existing manifolds are covered (well 98.94% of their code). Those new functions I will have to check, especially |
Thanks - I will submit the reformatted files - please bear with me if there
are further failed mails. If there is a quieter way for me to test before
resubmitting please let me know.
Du
…On Wed, Nov 30, 2022 at 8:28 AM Ronny Bergmann ***@***.***> wrote:
The other manifolds will work as soon as formatting is fine. As soon as a
first of the tests fails, no other is started and since we have groups of
tests, some were not run (see those with a gray (!) upfront in the list of
the checks, those were not run) so as soon as those do run, the existing
manifolds are covered (well 98.94% of their code).
Those new functions I will have to check, especially dot_exp is already
provided I think.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFPO27USH55INOFOCY3WK5I6BANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
Well if you have Manifolds on you machine in development mode, you can always also test your code locally with |
Thanks for the tip!
…On Wed, Nov 30, 2022 at 8:56 AM Ronny Bergmann ***@***.***> wrote:
Well if you have Manifolds on you machine in development mode, you can
always also test your code locally with ] test Manifolds. But even if you
only let the CI here check – that is still reasonably silent ;)
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFNI2QAVMSXHNK6SYLTWK5MIZANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
I did a push - it seems OK - please let me know!
…On Wed, Nov 30, 2022 at 8:57 AM Du Nguyen ***@***.***> wrote:
Thanks for the tip!
On Wed, Nov 30, 2022 at 8:56 AM Ronny Bergmann ***@***.***>
wrote:
> Well if you have Manifolds on you machine in development mode, you can
> always also test your code locally with ] test Manifolds. But even if
> you only let the CI here check – that is still reasonably silent ;)
>
> —
> Reply to this email directly, view it on GitHub
> <#555 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEOOGFNI2QAVMSXHNK6SYLTWK5MIZANCNFSM6AAAAAASO7CVTA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
--
Thanks,
Du
--
Thanks,
Du
|
Beside the tests in stiefel.jl, I did extensive tests in this repository
<https://github.com/dnguyend/MiscCollection/tree/main/MiscStiefelLogTest/misc_stiefel_frechet>
,
in particular, this workbook
<https://github.com/dnguyend/MiscCollection/blob/main/MiscStiefelLogTest/misc_stiefel_frechet/JuliaStiefelLogMiminizeLBFGS.ipynb>
…On Wed, Nov 30, 2022 at 12:04 PM Du Nguyen ***@***.***> wrote:
I did a push - it seems OK - please let me know!
On Wed, Nov 30, 2022 at 8:57 AM Du Nguyen ***@***.***> wrote:
> Thanks for the tip!
>
> On Wed, Nov 30, 2022 at 8:56 AM Ronny Bergmann ***@***.***>
> wrote:
>
>> Well if you have Manifolds on you machine in development mode, you can
>> always also test your code locally with ] test Manifolds. But even if
>> you only let the CI here check – that is still reasonably silent ;)
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#555 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AEOOGFNI2QAVMSXHNK6SYLTWK5MIZANCNFSM6AAAAAASO7CVTA>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
>
> --
> Thanks,
> Du
>
--
Thanks,
Du
--
Thanks,
Du
|
Formatting seems fine (you do not have to write a comment for every commit). Concerning the tests, well here in the CI we aim to have an – maybe small in dimension but – test that covers every line and still performs something we can check to be valid/correct. This doe snot say we do not have bugs, but (a) minimises the number of bugs, since you have to think about code lines a second time, namely what you expect as an outcome an write a test for that, but even more |
Ok, thanks! I hope the tests added in stiefel.jl conform to the general
philosophy. Happy to make any change if required.
I am quite impressed with the framework you guys set up.
…On Wed, Nov 30, 2022 at 12:31 PM Ronny Bergmann ***@***.***> wrote:
Formatting seems fine (you do not have to write a comment for every
commit).
Concerning the tests, well here in the CI we aim to have an – maybe small
in dimension but – test that covers every line and still performs something
we can check to be valid/correct. This doe snot say we do not have bugs,
but (a) minimises the number of bugs, since you have to think about code
lines a second time, namely what you expect as an outcome an write a test
for that, but even more
(b) the automatic tests (with high test coverage) make It easier to fix
bugs and modify/improve the code, because this way we can be sure it still
“behaves as expected”.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFN5PGINA6SLBKMREVDWK6FPTANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
The CI seems to have failed on installing matplotlib - which I don't think
I use. What should I do?
…On Wed, Nov 30, 2022 at 12:49 PM Du Nguyen ***@***.***> wrote:
Ok, thanks! I hope the tests added in stiefel.jl conform to the general
philosophy. Happy to make any change if required.
I am quite impressed with the framework you guys set up.
On Wed, Nov 30, 2022 at 12:31 PM Ronny Bergmann ***@***.***>
wrote:
> Formatting seems fine (you do not have to write a comment for every
> commit).
>
> Concerning the tests, well here in the CI we aim to have an – maybe small
> in dimension but – test that covers every line and still performs something
> we can check to be valid/correct. This doe snot say we do not have bugs,
> but (a) minimises the number of bugs, since you have to think about code
> lines a second time, namely what you expect as an outcome an write a test
> for that, but even more
> (b) the automatic tests (with high test coverage) make It easier to fix
> bugs and modify/improve the code, because this way we can be sure it still
> “behaves as expected”.
>
> —
> Reply to this email directly, view it on GitHub
> <#555 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEOOGFN5PGINA6SLBKMREVDWK6FPTANCNFSM6AAAAAASO7CVTA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
--
Thanks,
Du
--
Thanks,
Du
|
Work further locally on tests and documentation until is addressed / fixed :) |
Thanks, I saw the rerun, and I think there is one still going on.
On a rerun there was a fail comparing
log_lbfgs vs generating vector for the canonical metric - they look
sufficiently close (less than 9e-9) but failed - I believe in the local
test I forced the accuracy level to be higher - I probably will do it here.
There was an error for expm_frechet - absolute error was < 3e-3, probably
on a matrix with large eigenvalue. I will limit the largest eigenvalue and
resubmit the test script.
There was also a complaint on symplectic stiefel - but I presume that is
not related.
Have a good weekend!
α=0.5: Test Failed at
/home/runner/work/Manifolds.jl/Manifolds.jl/test/manifolds/stiefel.jl:568
Expression: isapprox(MM, p, Manifolds.log_lbfgs(MM, p, q), X)
Evaluated: isapprox(MetricManifold(Stiefel(4, 3, ℝ),
StiefelSubmersionMetric{Float64}(0.5)), [0.03692676533179337
0.7392015040180194 -0.6496424690154912; 0.38776641156841574
-0.24069024074501766 -0.013910854515959737; 0.8809850680488652
0.25081693802237826 0.2519849355176593; 0.26858692063542816
-0.5768363789400607 -0.7171295160919356], [0.0585973393258645
0.08436281749191825 0.11905892082509396; -0.12976266615385246
-0.6930079176321513 -0.7317602195557313; 0.15076133210137377
-0.13558784475699176 0.07866681264844064; -0.31522268101696455
0.3383171436064817 -0.06601801843791485], [0.05859734123700349
0.08436281763177483 0.1190589231066079; -0.12976266057166255
-0.693007929702738 -0.7317602231596487; 0.15076133133869893
-0.13558784471759106 0.07866681181496862; -0.31522268683725074
0.3383171488393988 -0.06601802072767841])
…On Thu, Dec 1, 2022 at 12:34 AM Ronny Bergmann ***@***.***> wrote:
Work further locally on tests and documentation until
JuliaPy/Conda.jl#229 <JuliaPy/Conda.jl#229>
is dressed / fixed :)
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFJHN7SFLU7247GFTTTWLA2FTANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
This reverts commit b4462ce.
instead of modifying runtest you can also just include that file yourself. We wrote the single manifold tests in a way that they also work standalone, that is only with Code coverage for a little bit better, but we are not yet there. |
Thanks. I added replies to the issues you raised above. I have been running test on single files. I would like to know the syntax to run one file and generate the coverage file, the .cov file generated next to the code showing what line of code is not covered, like these: [ Info: CoverageTools.process_file: Detecting coverage for src/manifolds/StiefelEuclideanMetric.jl Pkg.test("Manifolds", coverage=true) generates the .cov files, they are useful for me, but I had to modify runtests.jl to trick it to work - so it would be great to have a syntax to do it directly. I am able to get coverage for expm_frechet.jl and StiefelFrechet.jl to near 98%, only the views are now flagged as uncovered. I don't know how to fix the views - presumably there is an ignore option in the setup file ? expm_frechet.jl I haven't started on minimize_lbfgs.jl, this is a bit tricky as it is a general purpose optimizer - there are many scenarios - but I am working on it. |
I never did code cos for single files, since I usually work through all points of coverage and commit and look ad code con here.
Concerning this point – hm I am not much a fan of including code from other packages here, but if that is necessary, then relay only with a lot of documentation and notes where that is from (and a check of whether their License allows that of course) Concerning the
but did you write that yourself? Otherwise – and for code even more than for constants – I would be very unhappy to copy over code from other packages - and maybe if you write a more specialised solver it might both be faster and easier to test? |
Thanks - I will address the points you raised - By the way you mentioned
the docs for the PR run are activated - but I could not find the link -
could you please share ? The docs I generated locally look reasonable for
me.
Just quickly, if its relevant ( will add to the doc), the magic numbers on
expm_frechet comes from pade approximation (copied from scipy.linalg)
Concerning this point – hm I am not much a fan of including code from
other packages here, but if that is necessary, then relay only with a lot
of documentation and notes where that is from (and a check of whether their
License allows that of course)
I checked with the original article - and have added explanations - the
quoted paragraph was from Friday - which I believe have been addressed in
last night's run.
Concerning the @views that are false positives and they will sadly stay
(actually these false positives are the reason we are not at 100% Code
Coverage
minimize_lbfgs.jl, this is a bit tricky as it is a general purpose
optimizer
but did you write that yourself? Otherwise – and for code even more than
for constants – I would be very unhappy to copy over code from other
packages - and maybe if you write a more specialised solver it might both
be faster and easier to test?
you could see the coverage is 80% for this case - the remaining cases are
rarer cases - which could happen, some cases are just status messages when
the optimization problem fails to converge. I just have to work to cover
them all.
I just want to be proactive and explain where I am in the process - not
mean as an excuse, I am sorry if it sounds that way.
…--
Thanks,
Du
|
No worries, I am aware that you are in the process, I am just trying in a few steps to give feedback early to reduce your work (hopefully at least ;) ) |
The new push should bring the 3 files I work on much closer to target, but if there are still issues I will investigate. I added 4 functions out in the docs, expm_frechet, minimize (from minimize_lbfgs), dot_exp and log_lbfgs. The helper functions have comments in docstring format but does not show on the docs. |
I submitted a change this morning which should improve coverage for the 3
files to above 97%. Somehow the coverage summary seems to have crashed -
but the CI run is flagged as OK otherwise.
Please take a look when you get a chance - I hope it's not something the
code caused.
Other than that, I think the outstanding coverage issues are with @views,
and there is one rare condition in the optimizer which the next release
should fix.
…On Sun, Dec 4, 2022 at 12:33 PM Ronny Bergmann ***@***.***> wrote:
No worries, I am aware that you are in the process, I am just trying in a
few steps to give feedback early to reduce your work (hopefully at least ;)
)
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFINWAQZ4S3ALDJ3MG3WLTIWPANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
The first thing I see is that your test runs issue quite some output. That should never be the case, especially not something like
besides that maybe one of the reports (we gather 2, one for Lie groups one for manifolds) came too late (before this PR the manifolds test case ran for about an hour, your last test run was more than 1.5 hours it seems which is really long). |
I will remove the print out and will resubmit. Hope this will fix the
problem.
The one change I made to improve coverage is there are some "if" cases that
are rarely hit, so I run 50 log_lbfgs randomly (with stating seed) and get
all of them,
Probably 10+ runs among those 50 fill the missing cases but to restrict to
those I have to save actual manifold/manifold points.
…On Mon, Dec 5, 2022 at 11:28 AM Ronny Bergmann ***@***.***> wrote:
The first thing I see is that your test runs issue quite some output. That
should never be the case, especially not something like
i= 27 n= 93 k= 15
besides that maybe one of the reports (we gather 2, one for Lie groups one
for manifolds) came too late (before this PR the manifolds test case ran
for about an hour, your last test run was more than 1.5 hours it seems
which is really long).
So for now I am not 100% sure how to continue since it seems something in
your tests causes the second report not to be reported or being reported
too late.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFLOXVJ6DHJPSDOORI3WLYJ4BANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
Please do not do random tests – that is absolutely horrible to debug if one of the random cases fails, because it is super hard to debug – for any maintainer. I have such a case for about a year now I another package and was not yet able to reproduce the case in a non-random setting to finally fix it. So: Please no random stuff in the tests. |
if isnothing(s) | ||
# scaling | ||
s = max(0, Int(ceil(log2(A_norm_1 / ell_table_61[14])))) | ||
# pade order 13 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the goal of this comment if the next line calls a function of same name? And why are there so many other diff_pade13 functions? To more this file is a little chaotic and most of its content a little strange – sorry, but it is really mainly the problem that I will have to be able to maintain that and in its current form, this is just not possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will clean up - and make diff_pade13 calling diff_pade13!
t, | ||
) where {n,k} | ||
q = similar(p) | ||
dot_q = similar(p) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think dot_q
is a tangent vector, right? First of all, then dot_q
should be called diff_exp
or differential_exp
but even more, dot_q
should be initialised as a tangent vector (zero_vector(M,p)
probably) and better be called X
or Y
following our naming convention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK will do
Since I run into all these problems when I just take a 5 minute look at your code, I am slowly wondering how much time (and comments) it would take me (or the other maintainers) to take a look at more than a few lines of code and whether all the comments can be solved. Maybe it would be a better Idea if you do a small package yourself (based on ManifoldsBase) that implements this part? The advantage that way is
What do you think? |
Thanks - it is kind of unexpected - thanks for the suggestion. I will have to think about working on a new package - that will likely to take more time commitment than I can afford. By the way, I would like to share a paper Operator-valued formulas for Riemannian Gradient and Hessian and families of tractable that shows how to compute the Levi-Civita connection for most metrics, including Stiefel/Grassmann/Flag manifolds, semi-definite matrix manifold with a complete metric. I believe it also gives the connection for the Symplectic Stiefel manifold that is in your package. |
Thanks for the link. I am sorry that that will take more time, but keep in mind I am doing this in mz free time and have spent so much time on this already, and barely looked at about 20-30 lines of code. In that speed this PR is done (given that I spent an hour a day or such, like I did the last week here) this will take a very very very long time with a lot of time from my side. And sorry, I can not do that besides lectures, master and phd students and my own research. Besides that there are the questions with licensing that I am still not sure about since you did not answer that completely yet. In your own package – I would not care about your licensing – in mine I do. |
I will close this for now. Let me know if you need help with the additional package. This also does not mean we will never include this here, I just feel that it will need some time to mature. And as said, as you own package, you can depend on Optim, Manifolds, and whatever you want, so your first code here should be good to go for such a package :) |
Thank you for the offer - too bad this didn't work out.
…On Mon, Dec 12, 2022 at 2:43 AM Ronny Bergmann ***@***.***> wrote:
Closed #555 <#555>.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFNDU2AP3LHSCS4OZ53WM3JSVANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
As I mentioned – I can currently not provide the time to help you finish this, especially
and there seems to be no one else as well. If you at some point have these criteria fulfilled – feel free to reopen this PR or do a new one. But I feel starting from a separate package is really the best way to go here. An we are happy to link your project then. |
I understand. Thanks!
…On Mon, Dec 12, 2022 at 12:11 PM Ronny Bergmann ***@***.***> wrote:
As I mentioned – I can currently not provide the time to help you finish
this, especially
- documentation
- testing
- review all code lines and the design of the functions.
- Check dependencies and especially Licensing of code you include
and there seems to be no one else as well. If you at some point have these
criteria fulfilled – feel free to reopen this PR or do a new one. But I
feel starting from a separate package is really the best way to go here. An
we are happy to link your project then.
—
Reply to this email directly, view it on GitHub
<#555 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOOGFI2OG426KBMWAUJS43WM5MELANCNFSM6AAAAAASO7CVTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Du
|
I added log_lbfgs - please let me know! I added new tests to test/manifolds/stiefel.jl. Additional tests are in this workbook and the jl files in this directory