I was looking over the degree-Rips code and realized that it doesn't properly handle pseudometric spaces.
Specifically, the function BifiltrationData::generate_vertex_multigrades always adds a generator at index ((0,0) for each vertex, but for pseudometric spaces, that's not what we want. We need to count the vertices of distance 0 to each vertex. The effect is that there may be a generator at (d,0) for d>0, but RIVET will remove this via a call to BifiltrationData::update_grades and report that there is a generator at (0,0).
This is technically a bug, since the documentation (Section 8.3) says that RIVET accepts a distance matrix with some off-diagonal entries equal to zero. It could be an issue, e.g., for genetic data, where you might well see two copies of the same genome. In practice, when one visualizes degree-Rips bifiltrations in RIVET, one doesn't not worry so much about what is happening at r=0, which is why this didn't get noticed sooner. But it if course still needs to be fixed.
Fixing this may require some care, because of the way this code interfaces with the code for coarsening, but I will take care of it soon.
I was looking over the degree-Rips code and realized that it doesn't properly handle pseudometric spaces.
Specifically, the function BifiltrationData::generate_vertex_multigrades always adds a generator at index ((0,0) for each vertex, but for pseudometric spaces, that's not what we want. We need to count the vertices of distance 0 to each vertex. The effect is that there may be a generator at (d,0) for d>0, but RIVET will remove this via a call to BifiltrationData::update_grades and report that there is a generator at (0,0).
This is technically a bug, since the documentation (Section 8.3) says that RIVET accepts a distance matrix with some off-diagonal entries equal to zero. It could be an issue, e.g., for genetic data, where you might well see two copies of the same genome. In practice, when one visualizes degree-Rips bifiltrations in RIVET, one doesn't not worry so much about what is happening at r=0, which is why this didn't get noticed sooner. But it if course still needs to be fixed.
Fixing this may require some care, because of the way this code interfaces with the code for coarsening, but I will take care of it soon.