Add representative-cycles

[daytenjs]

Found on c++ package branch here: https://github.com/Ripser/ripser/tree/representative-cycles

I'm trying to do it but its not my skillset

[corybrunson]

On one hand, i am hesitant to incorporate experimental tools from the source into a release of the port.

On the other hand, if the experimental tool is mature, then i would be glad to work in a branch on a version that would enable R users to access it.

@rrrlw glad to follow your lead on this.

[daytenjs]

The Representative Cocycles branch is implemented in the Python implementation of Ripser if thats any help regarding the maturity. The representative-cocycles would also serve my purposes, but the representative-cycles is what I want. Having both of course would be even more useful :)

[rrrlw]

@corybrunson It would be great if you could work on this in a branch!

I think it would be most appropriate to have the current features packaged/released as the next major update. Then, we can include representative cycles/cocycles in a major/minor update after. Being in a branch would still allow users to use the functionality by installing the development version in the branch via the remotes package; but the CRAN release would remain stable throughout (and only be updated once the cycles/cocycles functionality has withstood the test of time). How does this sound?

[corybrunson]

@rrrlw i can work a bit on this over the summer—please assign me and check in if you remember to in June and July. : )

[corybrunson]

@daytenjs i'm sorry to walk back my plans! This is doable, but i would need more time than i currently have. Though i now agree that both features (cocycles and cycles) are high-priority and ready to write.

[daytenjs]

I'd be happy to try and help, I know little C++ (I do want to expand on that) but have much experience with R, having even written a few unreleased packages. I would love the chance to contribute, let me know!

[corybrunson]

@daytenjs if you'd like to test the waters in a new branch & fork then i will be glad to support you along the way! From my own similar experience, it can take a while to get comfortable with C++, but building something is the best way to.

Here're my observations from the source code:

• The representative-cocycles and representative-cycles branches of Ripser seem to have no inherent conflicts.
• The (co)cycles are printed by Ripser, and this code was amended to store the cocycles in SciKit-TDA. We want to do something similar through Rcpp.
• The naming conventions vary greatly between Ripser and SciKit-TDA; this can cause confusion. I urge us to adhere to those of Ripser by default, as the current C++ code does.

[michiexile]

representative-cocycles would be a highly valuable addition to Ripser in my opinion. It is crucial for doing circular coordinates (for eg intrinsic phase angles for quasi-periodic timeseries)