Open reds-heig opened 3 years ago
BTW, I didn't add test for this one. But I wasn't sure about the best way of adding them.
in_memory
is now an option when calling flagser_unweighted
or flagser_weighted
, meaning that we could reuse the same test and expect exact same results.
@ulupo do you have an idea on how to reuse the same test with a new parameter ? (I don't think it's necessary to run the heavy test on this option)
@MonkeyBreaker should we also go ahead with this PR?
I think that I should add a test, something simple. Compute Flagser on the same data, and expect same results. After that we can merge this, I will do it this week-end if it works for you.
After we merge new github actions, I will add the missing test and hope that all test passes. Should I also add a table showing examples of run with option enable/disable reporting runtime and memory consumption ? @ulupo what do you think ?
Thanks @MonkeyBreaker!
Should I also add a table showing examples of run with option enable/disable reporting runtime and memory consumption ? @ulupo what do you think ?
I think that some draft version of this would be very helpful, but let's not spend too much time on this!
This feature should be the main highlight of v0.4.6 :)
Reference Issues/PRs
61
What does this implement/fix? Explain your changes.
This PR integrates latest changes from
flagser
backend. In which the optionin_memory
is now available when computing homology. This options allows a tradeoff of using more memory in order to speed up computation.Any other comments?
In order to support the
in_memory
data structure, I needed to duplicatepersistence_computer_t
part that manages the part to retrieve results. In my opinion it's not the best way of doing this, but due to how retrieving values from results was implemented inflagser
I cannot see how to do differently. If anyone has a better solution/approach, please let me know !Quoting the author: