Extended and Relative homology

[mglisse]

Since several users have asked: we should provide an example showing how to use persistence to compute the relative homology of a complex and a subcomplex (mostly how to interpret the result).

[MathieuCarriere]

I agree. Extended persistence could also be interesting since I have received a few messages from people trying to use Gudhi for computing extended persistence.

[VincentRouvreau]

Was this issue fixed by #215 ? @mglisse @MathieuCarriere

[mglisse]

I don't think #215 contains an example showing how to compute the relative homology of a pair (L,K), so while it is related, it answers a different question.

[mglisse]

In a discussion, we mentioned the possibility of adding an API relative_betti_numbers(x,y) to compute the relative homology of (K_y, K_x).

[shilangyu]

Has there been any progress in this space? If not, what are the possible approaches to compute relative homology of a complex and its subcomplex using the current API? I'd be happy to contribute documentation upon some guidance.

[mglisse]

The simplest approach, when you have a small complex S included in a big complex B and you want their relative homology, is to construct the big complex, assign a filtration value of 0 to the cells of S and 1 to the others, and compute persistent homology. The relative homology is then just a matter of interpreting the diagram:

• intervals [0, inf) don't matter
• intervals [1, inf) count normally
• intervals [0,1) have a dimension shift (an edge that kills a connected component in persistent homology actually creates a cycle in relative homology)

Or something similar, I don't promise that I didn't write this too quickly.

[OnDraganov]

Coning is an easy alternative. It increases the complex size, but the result can be interpreted as-is.

If we have a pair (K,L), st is the SimplicialTree representing K, and subcomplex is the list of the simplices in L, we can just do the following:

new_vertex = len(points)  # gudhi uses vertices 0, ..., len(points) - 1
st.insert([new_vertex], 0)
for simplex in subcomplex:
    st.insert(simplex + [new_vertex], st.filtration(simplex))
st.compute_persistence()
relative_pd = st.persistence()

[hschreiber]

The following issues are merged with this discussion:

Issue #47

Original from @mglisse

Cover_complex::compute_PD Computes the extended persistence diagram of the complex

This is not sufficient documentation.

• Persistence_diagram is not documented
• How are extended diagrams represented? Usual points above the diagonal, and the ones that would be essential in non-extended end up below?
• What is it the persistence of? The sub-level sets of the associated function?

Issue #320

Original from @MathieuCarriere
In the current implementation of extend_filtration(), coning is done by creating a copy of the simplex tree in *this. It would save space to work on *this directly, which means playing with its private interface (create a new root, change parents/siblings etc).

[hschreiber]

I would also add another point: I think it would be cleaner to externalize the computation of the extended persistence from the simplex tree. We can keep only a general cone(Vertex_handle) method which would work with any options of the tree (which is not the case now) and move the rest to another module. Either a new module, or it could be put together with Persistent_cohomolgy. It could also be the occasion to add something for relative persistence as both are related.