Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

calculate_homology results #23

Open
SPRADA1 opened this issue Oct 21, 2020 · 4 comments
Open

calculate_homology results #23

SPRADA1 opened this issue Oct 21, 2020 · 4 comments
Assignees

Comments

@SPRADA1
Copy link

SPRADA1 commented Oct 21, 2020

Hi! When I use calculate_homology over a graph with 7 vertices (for example) I only obtain 6 features at dimension 0 and that start with a filtration weight 0, why is that? Shouldn't be 7 features? I couldn't find the reason in your guidelines or vignettes.
Thanks!

@rrrlw rrrlw self-assigned this Oct 21, 2020
@rrrlw
Copy link
Owner

rrrlw commented Oct 21, 2020

Thank you for the question. You are correct - for a graph with 7 vertices, there should be 7 zero-dimensional features that start at a filtration weight of 0. However, the 7th feature would be redundant. Let's assume that the closest pair of points within this set of 7 are 0.1 units apart. Then, the 2 features for the closest pair (one feature per point in the pair) would both start at 0 and both end at 0.1. This generalizes to all graphs (or point clouds) - the closest pair of vertices (or points) would result in 2 identical zero-dimensional features that start at 0 and end at the distance between the vertices (or points). Since the repeated feature does not add any new information, it can be safely excluded when calculating and returning the graph's (or point cloud's) persistent homology. If you'd prefer to include this feature, you can duplicate the zero-dimensional feature with the shortest persistence in the results that calculate_homology returns.

The above is the best explanation I have about the unexpected behavior (one less zero-dimensional feature than expected). However, keep in mind that the TDAstats R package uses Ripser as the underlying calculation engine. If this answer is unsatisfactory, it can be brought up as an issue in the Ripser GitHub repo.

This is the first time I am noticing the issue you brought up. First, thank you for meticulously checking results. Second, I would like to ensure that anyone else who has the same question is able to find the answer easily in this repo. I think either the function documentation for calculate_homology or within a vignette would be appropriate. As such, I will keep this issue open until it is included somewhere in the package.

I hope this helps, @SPRADA1. Please let me know if there's anything else.

@SPRADA1
Copy link
Author

SPRADA1 commented Oct 22, 2020

Thanks for your detailed answer! I see your point...is it related to the concept of "reduced homology"? I will write the same issue in the Ripser repo anyway so we have all the information :)
Thanks again!

@rosswsweet
Copy link

rosswsweet commented Jun 4, 2021

I'm not convinced that the issue is entirely due to the two closest points. The homology class associated to one of those points will vanish, but the other does not.

I'm seeing this issue as related to the threshold. In a toy example with 12 points (see below), setting the threshold value of 5 should yield a homology class with a birth of 0 and a "death" at 5. Indeed, when this data is input in Ripser Live (live.ripser.org) with the settings "point cloud," dimensions "0 to 1" and threshold "5," the expected barcode is returned, with 12 bars for each homology class, with the longest going to the threshold value of 5. However, using TDAstats, the longest bar we get is just larger than 4.

Thank you for your work on this package!

x,y
3,4
1,3
2.4,2.8
1.2,2.5
2.3,1.6
1.22,1.48
5,1
6.5,6
7,6.4
7.4,5.6
8.5,6
8.2,5.2

@rrrlw
Copy link
Owner

rrrlw commented Jul 2, 2021

I apologize for the late response. I will take a look shortly, thank you for bringing this up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants