Cool! Is @wildart, the author of ComputationalHomology.jl hanging out here? Does this support CW-inputs? (input: list of cells with dimension, sparse homology boundary matrix; complex is really CW and not simplicial / cubical / etc)
So, is it time for a julia computational topology org? That one could help consolidate data structures / formats, plotting, wrappers around external libraries like ripser / gudhi and generally make everything more modular. For example, receiving input metric spaces, generating sparse matrices (in case of sparips, with user-supplied error tolerances), computing homology/cohomology, visualizing output, and analyzing output (bottleneck distances, statistical analysis, whatever) want to be separate packages with clean interfaces that can be swapped out for each other.
Thanks for that! But it is not really super polished, and more of a proof-of-concept for the new algorithms.
There are so many warts that want to be fixed, e.g.:
What moron decided to stay with the initial point permutation, instead of choosing one of the many cache-oblivious / metric-locality aware memory layouts?
What moron decided to support error tolerances that are supplied by evaluation-oracle, without users supplying oracles for inverse and some more transforms? Especially the latter bites me in so many unforseen ways that it’s not even funny; yes, it is possible and very convenient for users; no, it was not a good idea in retrospect.