feat: added cubature recombination example.

[tc85324]

Closes #778

PR Type

• Feature
• Tests

Description

Adds a test to demonstrate the end-to-end usage of TreeRecombination
for constructing non-product cubature formulae from product cubature
formulae. A corresponding integration test has also been added for this
new example.

How Has This Been Tested?

The new tests pass locally and contain theoretically grounded assertions.

Does this PR introduce a breaking No

Checklist before requesting a review

• I have made sure that my PR is not a duplicate.
• My code follows the style guidelines of this project.
• I have commented my code, particularly in hard-to-understand areas.
• I have performed a self-review of my code.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• Any dependent changes have been merged and published in downstream modules.

[github-actions]

Performance review

Commit babd120 - Merge 199219b into 82ab5ec

No significant changes to performance.

[pc532627]

A few documentation comments - additionally the doc builds fail - this might be resolved simply by merging in main to this branch

[pc532627]

@tc85324 Related to end-to-end usage of recombination, I'd be interested in your thoughts on how to sensibly include Recombination into the benchmarking currently being done on PR #802 . In that PR, @qh681248 is exploring how the various coreset methods compare in terms of run-time and error (MMD, KSD, ...) on a suite of candidate test problems. Since recombination isn't an ExplicitSizeSolver direct comparisons to coresets from other methods of a given size may not be in some sense fair. We could exclude it from benchmarking because of this - but if you have any ideas on sensible ways to include it we'd be open to suggestions.

[github-actions]

Performance review

Commit 7869814 - Merge 87bc9d8 into 3463539

Statistically significant changes

• basic_rpc:
  • OLD: compilation 0.6253 units ± 0.03252 units; execution 0.142 units ± 0.001823 units
  • NEW: compilation 0.6109 units ± 0.02807 units; execution 0.1594 units ± 0.001063 units
  • Significant increase in execution time (12.22%, p=1.457e-13)

---

Normalisation values for new data:
Compilation: 1 unit = 369.59 ms
Execution: 1 unit = 784.78 ms

[tc85324]

@tc85324 Related to end-to-end usage of recombination, I'd be interested in your thoughts on how to sensibly include Recombination into the benchmarking currently being done on PR #802 . In that PR, @qh681248 is exploring how the various coreset methods compare in terms of run-time and error (MMD, KSD, ...) on a suite of candidate test problems. Since recombination isn't an ExplicitSizeSolver direct comparisons to coresets from other methods of a given size may not be in some sense fair. We could exclude it from benchmarking because of this - but if you have any ideas on sensible ways to include it we'd be open to suggestions.

Thank you for the review! Regarding benchmarking, I would say that the example in this pull is probably the canonical use case for recombination and it would be useful to have runtime performance figures for varying numbers of test-functions (dimension and degree), and in the case of TreeRecombination, tree_reduction_factor. While this won't be comparible to the ExplicitSizeSolvers it is useful from an implementaiton perspective as we can check/see if real world performance scales at the same/simlar rates to those claimed in the literature.