[Request] Implement density-based Mapper

[kalebruscitti]

🚀 Feature Request

I've got a generalization of Mapper called density-based Mapper that I find to be extremely useful for using Mapper in a temporal topic modelling context. I have my own scikit learn compliant implementation of it here, but your Mapper project is much better than mine and I think it would be better for me to contribute to your project instead of maintaining another version of Mapper.

🔍 Motivation

I am interested in temporal topic modelling problems. I am embedding a corpus of documents and reducing them with UMAP to 2- or 3- dimensions. These documents also come with timestamps. Using the timestamps as my Morse function, I then use Mapper to construct a graph where I interpret vertices as topics and edges as temporal relationships between topics.

In this context, my dataset often has a highly varying frequency across the dataset, and this means there is not a good choice of n_intervals that works for the entire dataset. To solve this, my density-based Mapper algorithm constructs different covers that account for the varying frequency across the dataset.

Empirically, we find that these covers generate Mapper graphs that perform much better for our applications.

🧠 Algorithm Details (Optional)

The main step in the paper is defining a type of cover that I called a Kerneled Cover; using a kerneled cover the rest of density-based Mapper is the same as standard Mapper. Therefore I think all we'd need to do is implement a KerneledCover class.

Let me know if this interests you! If it does, I'll try and draft a PR with an implementation.

[lucasimi]

Hi @kalebruscitti 👋
First of all, thanks a lot for working on this and for proposing it as an addition to the library.

The problem you're addressing is clear. At the moment, tda-mapper only provides a few relatively simple cover algorithms and, depending on the dataset, they may not always be a good fit (for example, StandardCover with a fixed n_intervals can become limiting when the lens dimension is high). For that reason, I agree this could be a valuable addition.

As you mentioned, it would likely require implementing a new Cover class. That said, depending on the complexity of the implementation, the number of dependencies involved, and the impact on the public API, I'd like to take a bit of time to evaluate the long-term maintenance implications (API stability, testing, documentation, compatibility, etc.) before deciding on the best way to integrate it.

I'll read the paper and code you provided, review this more carefully, and get back to you soon.

Thanks again for the contribution!

[kalebruscitti]

The paper is not super well written (I have a better draft in progress) so if you have any problems reading it please don't hesitate to ask me!

Thanks for your time.