Multiparameter simplextree, C++ part. #976

DavidLapous · 2023-09-28T16:11:45Z

Cpp part of PR #817.
List of changes :

new is_multi_parameter flag in the simplextree's options to deal with filtration values that behave as array-like instead of float-like.
Filtration values are now as const ref to prevent array-like copies
- This implies adding static members for trivial filtrations : null_value and inf_
new member filtration_mutable to have a non-const access to the filtration.
For multiparameter filtrations, deactivated the assign behavior of the insert to prevent unwanted behaviors (and stay 1-critical). The filtration property is no longer maintained.
New array-like structure as Filtration_value, child of std::vector with numpy-like pointwise operations, in Simplex_tree/multi_filtrations/Finitely_critical_multi_filtrations.h
The Simplex_tree/Simplex_tree_multi.h contains the options of a simplextree multi, functions that can convert a 1-parameter simplextree to a multiparameter simplextree and vice versa, aswell as useful functions to push filtration values on a discrete grid (for discrete computations.
I also copied the unit tests of the simplextree to apply them to this new structure.

Feel free to move files/functions if they don't follow Gudhi's standard, or commit if its moral changes.

src/Simplex_tree/include/gudhi/Simplex_tree/multi_filtrations/box.h

src/Simplex_tree/include/gudhi/Simplex_tree/multi_filtrations/finitely_critical_filtrations.h

src/Simplex_tree/include/gudhi/Simplex_tree/multi_filtrations/line.h

src/Simplex_tree/test/simplex_tree_multi_unit_test.cpp

src/Simplex_tree/include/gudhi/Simplex_tree/multi_filtrations/finitely_critical_filtrations.h

src/Simplex_tree/include/gudhi/Simplex_tree.h

Co-authored-by: Vincent Rouvreau <[email protected]>

…ns.h

VincentRouvreau · 2023-09-29T13:25:56Z

src/Simplex_tree/include/gudhi/Simplex_tree.h

   private:
    Filtration_value filt_;
  };
  struct Filtration_simplex_base_dummy {
    Filtration_simplex_base_dummy() {}
    void assign_filtration(Filtration_value GUDHI_CHECK_code(f)) { GUDHI_CHECK(f == 0, "filtration value specified for a complex that does not store them"); }
-    Filtration_value filtration() const { return 0; }
+    const Filtration_value& filtration() const  { return null_value; }
+    static constexpr Filtration_value null_value={};


If we say:

struct MyOptions : Simplex_tree_options_multidimensional_filtration { // is_multi_parameter but not store_filtration static const bool store_filtration = false; }; Simplex_tree<MyOptions> stree;

We are facing the error:

gudhi-devel/src/Simplex_tree/include/gudhi/Simplex_tree.h:165:39: error: the type 'const Filtration_value' {aka 'const Gudhi::multiparameter::multi_filtrations::Finitely_critical_multi_filtration<float>'} of 'constexpr' variable 'Gudhi::Simplex_tree<MyOptions>::Filtration_simplex_base_dummy::null_value' is not literal static constexpr Filtration_value null_value={}; ^~~~~~~~~~

But maybe this error is normal ? I was wondering to see if we should static_assert some error in this weird case.

A static_assert could be a good idea, as the multi parameter tree only differentiate it self from the standard with its filtration values. If store_filtration == false, is_multi_parameter set to true makes no sense. But the problem could also be solved by removing null_value (see Issue #977), then we can just document that is_multi_parameter is ignored if store_filtration == false.

A simple fix is to do a static_assert(!store_filtration || is_multi_parameter). thoughts ?

I guess you meant static_assert(store_filtration || !is_multi_parameter) instead?

hschreiber · 2023-09-29T12:51:39Z

src/Simplex_tree/include/gudhi/Simplex_tree.h

+  static const Filtration_value& filtration(Simplex_handle sh){
    if (sh != null_simplex()) {
      return sh->second.filtration();
    } else {
-      return std::numeric_limits<Filtration_value>::infinity();
+      return inf_;
+    }
+  }
+  static Filtration_value& filtration_mutable(Simplex_handle sh){
+    if (sh != null_simplex()) {
+      return sh->second.filtration();
+    } else {
+      return inf_;


Already from the previous PR:

I am wondering if we could not just keep the version with the non const, as the validity of the filtration in the simplex tree is already responsibility of the user. This would avoid having to find a different name when it does exactly the same thing than filtration(). Or could there be performance issues when using non const references for numerical values (i.e., when the simplex tree is not multi)? If it is the case, an ugly way to solve this would be to return a std::conditional to switch between Filtration_value& and Filtration_value depending on the value of is_multi_parameter.

I don't have a fixed point of view on this. So its only a matter of what's the gudhi style of accessing a filtration value by reference.

If they really do the same thing, I am ok with filtration returning a non-const reference. But I wonder if filtration_mutable actually needs to return infinity for the null simplex. If we decided instead that filtration_mutable only accepts real simplices (GUDHI_CHECK that sh!=null_simplex()), it could make sense for it to be a separate function, and it would let us declare inf_ const.
IIRC (that was a while ago, so I am likely wrong), handling null_simplex was mostly for convenience for the output of persistent cohomology, not some fundamental reason.