WIP: Refactor inference modules

[kaiserls]

Description

This pull request addresses architectural limitations highlighted in issues #134 and #42. While the current design is effective for a stable prototype and generating results, it lacks flexibility for future extensions. Building on the refactoring efforts in #141 and #142, this PR restructures the framework to allow more flexible and modular usage.

Key Changes

1. New Subpackages:

• evaluation: Handles kernel density estimation and the mapping of densities between data and parameter spaces.
• inferences: Manages different approaches to selecting points for density evaluation:
  • sampling: Dynamically generates points based on the density of previous points.
  • grids: Uses a predefined set of points, enabling straightforward operations like chunking for multiprocessing.
• samplers: Encapsulates dependencies on specific samplers for sampling-based inference.

2. Implementation of the Dependency Inversion Principle:

• The dense_grid no longer depends on the InferenceTypes or calc_kernel_width. Instead it relies on the abstract KDE class, which serves as a callable interface.
• The evaluate_density function no longer requires direct access to data, kernel_width, or the hardcoded eval_gauss_kde function. Instead, it operates via the KDE interface.
• Enums such as InferenceType and DenseGridType are no longer used globally but only locally, in the inference and dense_grid respectively.

This pull request fixes #134 and allows to implement #42 quickly.

The dependency graph of eulerpi before the refactoring at commit 627ecab. Many of the dependencies are not visible, because this graph only contains modules, not classes.

Current dependency graph, the larger number of nodes is caused by splitting modules with multiple classes into separate files.

And a overview over the external dependencies

Question

• Do we want/should support evaluation multiple slices at once, directly?
• Should we reintroduce num_runs in the sampler The reason for the sub_runs was to have some fault tolerance. I am not sure if our package should take care of that or whether the details should be handled by the sampler. The user can still loop over the sampling by using continue_sampling.

Help wanted

• Update / Rewrite the very complex result manager
• Update the usage of the result manager

TODOs:

• Finish the refactoring:
  • Simplify and unify the different inference functions
  • Bring the dependency on the concrete KDE, and Grid to the inference call.
• Fix the documentation:
  • cleanup the auto-generated files and check the navigation bar
  • update the code examples - could also use automatic testing https://www.sphinx-doc.org/en/master/usage/
    extensions/doctest.html
• Check for performance regression
• Write the changelog

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please note/describe at least one tests that you ran to verify your changes.

• Local tests

Checklist For Contributor

• My code follows the style guidelines of this project (I installed pre-commit)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I wrote my changes in the changelog in the [unreleased] section
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

Checklist For Maintainers

• Continuous Integration (CI) is successfully running
• Do we want to release/tag a new version? [✔️ / ❌]
  • If yes, add a release to the changelog and set the new version in pyproject.toml. After the merge, tag the release!

[castellinilinguini]

I believe this is a great idea, this PR should greatly improve readability, maintainability & separation of concerns. Just to make sure I got this right: In the end, dense grids, sparse grids, and MCMC samplers would be implemented in the sampling submodule, right?

Edit: Nevermind, I just saw you did two different submodules for that, which makes sense ofc!

[kaiserls]

Discussion Result: Refactor as a class with name LogDensityEvaluator(FunctionWithDimensions)

[kaiserls]

Discussion Result: Refactor as a class with name DensityEvaluator(FunctionWithDimensions)

[kaiserls]

Discussion Result: Offer functional interface inference, but use object oriented approach internally

[kaiserls]

Discussion Result: Reintroduce subruns