gudhi/gudhi-devel

The GUDHI library is a generic open source C++ library, with a Python interface, for Topological Data Analysis (TDA) and Higher Dimensional Geometry Understanding.

The GUDHI library is a generic open source C++ library, with a Python interface, for Topological Data Analysis (TDA) and Higher Dimensional Geometry Understanding. The library offers state-of-the-art data structures and algorithms to construct simplicial complexes and compute persistent homology.

Source code

We recommend that users get official releases from the GUDHI website.

For potential contributors, to fully checkout GUDHI, after cloning the git repository, you may also need to checkout its submodules using

git submodule update --init

Compilation and installation

To install GUDHI, you can follow the C++ compilation procedure, the Python compilation procedure, use our conda-forge package, or go with Docker.

More information

• The GUDHI website
• Contact us
• Subscribe to the GUDHI users mailing list
• Tutorials
• Changelog

gudhi-devel's Issues

[Persistence_representations] Missing `inline` for many functions

Trying to link together 2 files that both include gudhi headers, I get many "multiple definition" errors from the Persistence_representations module. Some examples:
Gudhi::Persistence_representations::read_persistence_intervals_in_one_dimension_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, double), Gudhi::Persistence_representations::PSSK::construct(std::vector<std::pair<double, double>, std::allocator<std::pair<double, double> > > const&, std::vector<std::vector<double, std::allocator<double> >, std::allocator<std::vector<double, std::allocator<double> > > >, unsigned long, double, double), Gudhi::Persistence_representations::Persistence_intervals::Persistence_intervals(char const*, unsigned int), etc.

There is also Gudhi::Persistence_representations::epsi. Making this variable const would work. If it is supposed to remain writable, since we can't use C++17 inline variables yet, it is a bit more complicated.

[Python - documentation] body_max_width is not a valid option for 'classic' theme

Sphinx Python documentation fails on some system because of:

   html_theme = 'classic'
   html_theme_options = {
   ...
      "body_max_width": "1200px",

Regarding
https://github.com/sphinx-doc/sphinx/blob/master/doc/theming.rst body_max_width option
is only available for 'basic' theme.

[doc] OFF file format

The link to http://www.geomview.org/docs/html/OFF.html documenting the OFF file format we use for point sets is repeated in many packages, but not all that use it (for instance the tangential complex, or the python interface). Maybe we should link to our file_formats page, and explain there what variants we support, with an example for a point set so people are not too confused with having to specify edges/faces (just say there are 0).

[Cython - setup.py] setup.py shall declare dependencies

setup.py shall declare dependencies (numpy, cython, sphinx, matplotlib).
cf. progressivis setup.py attached file.

[CMake - global] Missing a "Hello world GUDHI" example

In the installation manual, a paragraph on how to compile a "Hello Gudhi" program outside of the gudhi directory would perhaps help.
Detail CGAL and GUDHI

[Persistent_cohomology - doxygen] Persistent_cohomology receive an object of type Complex_ds and not of type Filtered_complex in the documentation

Why does the constructor of Persistent_cohomology receive an object of type Complex_ds and not of type Filtered_complex? I assume that it is the same?
=> Both are the same problem, missing a comment to make doxygen pick them up.

[Sparse Rips complex] Construction from a distance matrix do not work

The following example : https://gist.github.com/VincentRouvreau/4d3f7951fafd4847cd62443a084070e5
shows how to construct a sparse rips complex from a distance matrix.
The crash seems to come related to choose_n_farthest_points function when using a distance matrix.

[Persistence_representations - Persistence_heat_maps] create_Gaussian_filter ignores its second argument

#include <iostream>
#include <gudhi/Persistence_heat_maps.h>

int main(){
  int n=2;
  auto a=Gudhi::Persistence_representations::create_Gaussian_filter(n,.1);
  auto b=Gudhi::Persistence_representations::create_Gaussian_filter(n,10);
  for(int i=0;i<a.size();++i){
    for(int j=0;j<a[0].size();++j){
      std::cout << a[i][j] << ' ';
    }
    std::cout << '\n';
  }
  std::cout << '\n';
  for(int i=0;i<b.size();++i){
    for(int j=0;j<b[0].size();++j){
      std::cout << b[i][j] << ' ';
    }
    std::cout << '\n';
  }
}

prints

0.000106789 0.00214491 0.00583047 0.00214491 0.000106789
0.00214491 0.0430817 0.117108 0.0430817 0.00214491
0.00583047 0.117108 0.318333 0.117108 0.00583047
0.00214491 0.0430817 0.117108 0.0430817 0.00214491
0.000106789 0.00214491 0.00583047 0.00214491 0.000106789

0.000106789 0.00214491 0.00583047 0.00214491 0.000106789 
0.00214491 0.0430817 0.117108 0.0430817 0.00214491 
0.00583047 0.117108 0.318333 0.117108 0.00583047 
0.00214491 0.0430817 0.117108 0.0430817 0.00214491 
0.000106789 0.00214491 0.00583047 0.00214491 0.000106789 

i.e. the same thing whatever sigma we use. The code looks like it is using sigma, but it actually simplifies out (up to rounding errors of course).

[Persistence_representations - Persistence_heat_maps] Simplify distance_from_diagonal_scaling

distance_from_diagonal_scaling and squared_distance_from_diagonal_scaling have complicated implementations with pow, sqrt, etc (all missing std::). As far as I can tell, up to a multiplicative constant (which we can probably omit), the first one should be just std::abs(p.second-p.first) and the second one the square of p.second-p.first.

[Nerve GIC] document what persistence compute_PD returns

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?

[python - install] make install does not install properly

make install copy the python library in directory lib/python3.6/site-packages/cython/ while python setup.py install copies the library in directory lib/python3.6/site-packages/

[Alpha_complex] Building a Delaunay triangulation (without filtration)

I have seen several times people use Alpha_complex to build a Delaunay triangulation, and then ignore the filtration values (overwrite them with other values). IIRC, computing the filtration values is by far the most costly part of Alpha_complex, so this seems wasteful. It could be nice to have an option to say that we don't care about the filtration values.
An alternative way to resolve this would be to have a (simple, copy-pastable) example showing how to build a Simplex_tree representing the Delaunay triangulation of a point cloud, possibly using CGAL's python interface (or anything simple).

[CMake - TBB] TBB requires to link against libatomic on some non-x86_64 architectures

Some non-x86_64 architectures seem to require explicitly linking against libatomic for the things that use TBB. I'm currently just adding it to the list of TBB libraries. Perhaps CMake can do something more intelligent on the architectures where it's needed?
https://git.nonempty.org/debian-gudhi/tree/debian/patches/0007-Force-linking-against-libatomic-for-parts-that-use-T.patch?h=debian/sid&id=fed62e52ab396f0d6ba9029f12d5ef35d7761989

[Global - Third party libraries] Make compilation fail if 1/3 party libraries are not installed for external projects

Compilation shall fail if 1/3 party libraries are not installed for external projects, modulo gudhi_patches for CGAL.

[CMake - general] Modify missing modules list in function of third parties library version

GUDHI_MISSING_MODULES and GUDHI_MODULES shall be set properly when in function of third parties library presence and version.
This may require to separate Witness complex of its Euclidean version (that requires CGAL).
This may require to separate Alpha complex (CGAL >= 4.7.0 and Eigen3) of its 3D version (CGAL >= 4.11.0 and Eigen3).

[Global - Copyright] Python Copyrights mention that Gudhi is a generic C++ library, but no mention about Python

The actual Copyrights says:
This file is part of the Gudhi Library. The Gudhi library (Geometric Understanding in Higher Dimensions) is a generic C++ library for computational topology.
It shall say:
This file is part of the Gudhi Library. The Gudhi library (Geometric Understanding in Higher Dimensions) is a generic C++ library, with a Python interface, for computational topology.
All Copyrights to be modified.

[Simplex_tree] shallow move constructor

The memory issue is due to something like a shallow move constructor of
'Simplex_tree' class in Simplex_tree.h:
In 'Simplex_tree' class, 'root_' is of type 'Simplex_tree::Siblings =
Simplex_tree_siblings' and 'filtration_vect_' is of type
'std::vector<Simplex_handle>'. Both type contains 'Simplex_tree_siblings
*', and a 'Simplex_tree' class variable contains the pointer to its
'root_'. Hence, when the move constructor is called, then the address of
'old.root_' is still preserved in new 'Simplex_tree', although 'old' is
deleted.
So I temporarily disabled move constructor so that copy constructor is used
instead.
And I guess to fix it, the address of 'old.root_' should be updated to the
new address of 'root_' in the move constructor.
uncles_ shall be updated somewhere.

[Bottleneck_distance - documentation] Distance computation shall be better documented.

An example of Bottleneck distance would help user comprehension.
It shall be mentioned that the Euclidean distance is not used.

[Simplex_tree] Simplex_tree insert functions handles badly duplicated vertices in list

st = gd.SimplexTree()
st.insert([0,1])
st.insert([1,2])
st.insert([1,1]) # No error, even return True 

print(st.get_filtration()) # => crash

Seems to come from insert_simplex_and_subfaces. Check insert function behaviour

make_filtration_non_decreasing in Alpha_complex_3d

gudhi-devel/src/Alpha_complex/include/gudhi/Alpha_complex_3d.h

Line 568 in a33d17e

complex.make_filtration_non_decreasing();

I wonder if this is always necessary. At least in the exact case I don't think it is, I am not sure about the safe and fast cases. Anyway the current code is safe, and I doubt the cost matters, this is more of a remark.

Recommend `-DCMAKE_BUILD_TYPE=Release`

In the documentation (say python installation), we show commands to build gudhi, and in particular we show cmake ... Doing this, we get the "CGAL performance notice" which recommends adding -DCMAKE_BUILD_TYPE=Release. Should we add this argument in the doc? Or if for some reason it does not apply, should we disable the warning with CGAL_DO_NOT_WARN_ABOUT_CMAKE_BUILD_TYPE=TRUE?

left-over debug printing in python SimplexTree.get_cofaces

import gudhi
st = gudhi.SimplexTree()
st.insert([0,1])
st.insert([0,2])
print(st.get_cofaces([0],1))

The call to get_cofaces prints stuff. I don't think it should, cython/include/Simplex_tree_interface.h should not have any std::cout in it (except if we add a function print or dump).
By the way, the name Complex in that file is misleading, get_cofaces returns a chain (a list of simplices) that does not form a complex (boundaries are not included).

[python - subsampling] sparsify_point_set wrong documentation

It looks like the python documentation for sparsify_point_set was copy-pasted from pick_n_random_points and only half updated. The points are not picked randomly, and min_squared_dist is not an integer.

[python - CMake] Re use add_cython_target from scikit-learn

Check if src/cython/CMakeLists.txt could re-use add_cython_target from scikit-learn

[Cython - persistence_graphical_tools] persistence barcode are not nice

Persistence needs to be sorted before by dimension, then by birth date.
They are sorted by dimension, then by life length for the moment

Python module for statistical procedures

Hi all,

I am working on a set of statistical procedures (in python) for persistence diagrams (in the spirit of the TDA R package ).
Other statistical procedures for other persistence representations will be also implemented as soon as these representations will be available in Python.

Should I organize all these codes in a new module called "persistence_statistics" ?
Suggestions for the name of this new module are welcome.

Thanks

Bertrand

[Cython - simplex_tree] There is no simplex iterators

We have to use get_filtration() to find the list of simplices.
There shall be an simplex iterator (cf.itertools)

[python] A Cmake option to set/unset runtime_library_dirs

Debian disallows setting rpath, so I'm currently unsetting runtime_library_dirs for the Python extensions. Could this perhaps be made into a CMake option?
https://git.nonempty.org/debian-gudhi/tree/debian/patches/0005-Don-t-set-runtime-library-dirs-for-Python-extensions.patch?h=debian/sid&id=fed62e52ab396f0d6ba9029f12d5ef35d7761989

[python] nogil

Cython has mechanisms to handle the GIL. I believe some of our C++ functions could be marked with nogil at least, we should investigate that at some point.

[tangential complex] Documentation improvements

(this is for the python doc, but the C++ one likely has the same issue)

• The user manual presents an example with 4 points and claims that for each point we are going to estimate its tangent subspace. Of course, with 4 points, we aren't going to get good estimates of the tangent subspace at each point... This is super-simplified, normally you have at least dozens of points. Besides, we only claim that we can reconstruct closed curves. Maybe a simple sentence explaining exactly that would help un-confuse users.
• The manual says "For each point p, estimate its tangent subspace Tp (e.g. using PCA)." The current code is hard-coded to use PCA, as far as I can tell from the doc (it would be nice if it allowed to plug other tangent space estimators). The sentence kind of gives a reader the impression that they are responsible for this tangent space estimation and they should look into PCA or alternatives, when (currently) that's an implementation detail that users cannot access.

[Bitmap_cubical_complex] Perseus file reader rejects infinity

read_perseus_style_file uses istream::operator>>(double&) to read numbers, which does not accept Inf (we had the same issue with other readers before). But that would seem like a useful thing to support, people regularly ask how to handle partial cubical complexes (with missing cells) and setting the filtration value to +Inf is the best we can currently offer.

[tangential complex] Uses undocumented CGAL functions

insert_if_in_star is a CGAL function that is not documented, but we are still using it. This could also be solved on the CGAL side by documenting those functions...

Missing example of witness complex from distance matrix

It would be nice to have an example showing how to build a witness complex starting from a distance matrix (select a set of landmarks, build the nearest landmark table, etc). I believe there used to be such an example in C++ a long time ago but it got removed. http://gudhi.gforge.inria.fr/doc/latest/group__witness__complex.html claims that example 3 is using a distance matrix, but that's not true. It would also help to use non-integral distances in the example so they are less easily confused with indices.

Trying to write such code in python, the format of the nearest landmark table is not convenient, it contains both integers and floats and thus cannot be a numpy array. I was starting from a distance matrix in a numpy array, selecting a set of landmarks, keeping only the corresponding columns in the matrix. Then I can either argsort or sort the rows but it is inconvenient to get both results mixed so I can pass the result to the witness complex.

[Alpha_complex] new do_sqrt argument

The filtration values we use in the alpha complex are squared radii. Most applications are more interested in a (non-squared) radius. We use squares because if we add weights, taking the square root becomes less meaningful, in particular if the value becomes negative. But I think we should make it as easy as possible for people to get the square root they expect, and a parameter seems to be the easiest, passing do_sqrt=True if we want the square root. The name do_sqrt is just a placeholder for the report, better names are welcome.

[Simplex_tree] Rules of 5 is violated

Missing move and copy assignement.

    Simplex_tree& operator=(const Simplex_tree& other) // copy assignment
    {
         ...;
    }
    Simplex_tree& operator=(Simplex_tree&& other) noexcept // move assignment
    {
        ...;
    }

[Global - utilities] use exit(-1) instead of std::abort in utilities

Use

exit(-1);

instead of

std::abort();

in utilities because it generates a sigabort when asking for help which can be confusing.

[CMake - doxygen] Doxyfile shall be generated

src/Doxyfile shall be generated by CMake to set the version from CMakeGUDHIVersion.txt
IMAGE_PATH shall be set from GUDHI_MODULES_FULL_LIST

[Simplex_tree] reset_filtration

A function that resets the filtration of all simplices to a given value could be useful, especially in python where iterating on all simplices is slow.
For instance, I may build a Delaunay triangulation using Alpha_complex. I set new values on the vertices and want the corresponding lower-star filtration (the filtration of a simplex is the max of its vertices). make_filtration_non_decreasing does that if the filtration values of edges, etc are -infinity before, but if the existing filtration values are larger, it gives something different.
I imagine something like st.reset_filtrations(new_value=0, min_dimension=0).

[python - global] Additional information on how GUDHI was compiled could help to debug users problems

import gudhi
gudhi.__version__
'2.2.0'

gudhi.__cgal_version__, tbb, eigen3, ... could be helpful.
And more generally, a gudhi.__info__ with a summary would be nice.

[CMake - global] List all that is missing

It would be good if CMake could list all that is missing (cython, ...).

[python - SimplexTree] boundary of a simplex

We have python interfaces for the inefficient access to coboundaries (get_cofaces), but we seem to be missing access to the more natural boundaries...

[RipsComplex] max_edge_length documented with type 'int'

"""RipsComplex constructor.

:param max_edge_length: Rips value.
:type max_edge_length: int

This should probably be float or whatever python calls it.

[Simplex_tree] make_filtration_non_decreasing return doc

@return The filtration modification information.

(same in python) is not clear at all, should be something like

true if any filtration value was modified, false if the filtration was already non-decreasing.

[Python - sphinx] Travis (Mac OS) ImportError: cannot import name 'main' from 'sphinx'

$ ctest -R sphinx_py_test -V
UpdateCTestConfiguration  from :/Users/travis/build/GUDHI/gudhi-devel/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/Users/travis/build/GUDHI/gudhi-devel/build/DartConfiguration.tcl
Test project /Users/travis/build/GUDHI/gudhi-devel/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 30
    Start 30: sphinx_py_test
30: Test command: /usr/local/Cellar/cmake/3.14.2/bin/cmake "-E" "env" "PYTHONPATH=/Users/travis/build/GUDHI/gudhi-devel/build/src/cython" "/usr/local/bin/python3" "/Users/travis/build/GUDHI/gudhi-devel/src/cython/doc/python3-sphinx-build.py" "-b" "doctest" "/Users/travis/build/GUDHI/gudhi-devel/src/cython/doc" "/Users/travis/build/GUDHI/gudhi-devel/build/src/cython/doctest"
30: Test timeout computed to be: 10000000
30: Traceback (most recent call last):
30:   File "/Users/travis/build/GUDHI/gudhi-devel/src/cython/doc/python3-sphinx-build.py", line 8, in <module>
30:     from sphinx import main
30: ImportError: cannot import name 'main' from 'sphinx' (/Users/travis/Library/Python/3.7/lib/python/site-packages/sphinx/__init__.py)
1/1 Test #30: sphinx_py_test ...................***Failed    0.20 sec
0% tests passed, 1 tests failed out of 1

[Tangential_complex] Imputing only consistent stars does not to work properly

Imputing only consistent stars using tc.create_complex(stree_consistent, false );
does not to work properly

[python - persistence_graphical tools] It would be nice to accept list of tuple(birth, death) as input

It would be nice to accept list of tuple(birth, death) as input and not only tuples(dimension, tuple(birth, death))

Remove references to gitlab

Since the gitlab thing was closed, those are dead links.
Do we get reports about dead links on the gudhi website?

[Cmake - Qt5] CMake outputs an error when Qt5 is not installed

CMake outputs an error when Qt5 is not installed.
In src/GudhUI/CMakeLists.txt find_package is not REQUIRED may be QUIET mode will fix the issue.

[data] Make COPYRIGHT clearer

The following files were deleted from the upstream sources in order to comply with Debian policy.

• GudhUI/utils/homsimpl : precompiled binary
• data/filtered_simplicial_complex/bunny_5000_complex.fsc : unclear license
• data/points/COIL_database/* : unclear license
• data/points/SO3* : unclear license
• data/points/bunny* : restrictive license (free for research use only)
• data/points/human.off : unclear license

[Persistent_cohomology] get_persistent_pairs function is not documented

The C++ and Python function is badly documented. Shall be better explained.