Umberto Lupo

We didn't do it (properly) for ``giotto-tda`` because ``conda-forge`` did not handle git submodules well if I recall correctly (maybe this is different now). Maybe the same problems would be...

I've started something [here](https://github.com/conda-forge/staged-recipes/pull/20147) taking inspiration from https://github.com/conda-forge/staged-recipes/pull/18571/files and https://github.com/conda-forge/staged-recipes/pull/17937.

> Should we use a different name than do_cocycles ? Even if longer, I would slightly prefer `return_cocycles`. Reason: one can "do" a lot of computation without returning anything.

> Sure, should it be an argument of function ripser_parallel or should we pass it via kwargs ? Are you asking if it should be positional or keyword-based with a...

Thanks a lot @michiexile! Do you think there is a bug in the cocycles implementation in this PR, or in the necessary post-processing to produce the graphics?

I see. Since `giotto-ph` does not include greedy permutations, I'd assume things should work just as they would in `ripser.py` when greedy permutations are not used there. Would this be...

@MonkeyBreaker thanks for chasing the issue and fixing it! @michiexile returning the distance matrix (as `ripser.py` does) would be very simple to implement. One could either do it automatically when...

I'm on vacation now and can only reply very briefly but this is just to say that returning the coboundary matrix may not be a terrible idea if it saves...

@MonkeyBreaker, thanks for the comments! What I meant to say initially is that we could compute the coboundary matrix in pure Python, as I already partly did that work for...

Indeed there is a speedup, at least anecdotally. Sorry I don't have time right now to give you a comprehensive benchmark test, but here are some very quick numbers from...