Non-discrete metadata

[cerebis]

How feasible would it be to extend infomap to support encoding numerical (or even ordinal) metadata?

Such as a node quantity that varies over the unit interval, and for which it is expected that clusters of nodes should have similar values.

[antoneri]

Hi, thanks for reaching out!

We have one current approach to doing this by creating a metadata-dependent encoding graph. Here's the paper: Mapping nonlocal relationships between metadata and network structure with metadata-dependent encoding of random walks.

Let me know if this suits your needs or if you have any questions!

[cerebis]

This article seems to be extremely relevant, thanks for pointing it out.

Was any supporting code also released? I didn't see any URLs that pointed to non-data resources. I ask as, although it seems the work depends largely on graph construction, I wasn't sure if the standard release of Infomap was all that was required.

[antoneri]

You are correct that it's centered around constructing a new graph. We have thought about extending the map equation but haven't done anything so far.

We have some messy research code here: mapequation/color-map-equation.
The main part is written in Rust for speed, but for small networks, it's easy to write it in Python.
Let me know if you want me to clarify anything!

[cerebis]

Sure, I have been exploring that codebase today. I see that the notebook (lazega) is set up to generate results for different values of categorical "gender". Although that's working, I noted that further down the notebook, there is a missing function `generate_links()`. Regardless of that, I tried adapting that work to call simulation for real-valued metadata, however, I am uncertain what would be a reasonable `s` and `b` (manuscript equation 8). I have been trying age, and years at firm, but the clustering response makes me think I am far away from sensible values. Also, should this discussion be moved to that repository? Regards, Matt DeMaere

…

On Wed, 23 Aug 2023 at 6:31 pm, Anton Holmgren ***@***.***> wrote: You are correct that it's centered around constructing a new graph. We have thought about extending the map equation but haven't done anything so far. We have some messy research code here: mapequation/color-map-equation <https://github.com/mapequation/color-map-equation>. The main part is written in Rust for speed, but for small networks, it's easy to write it in Python. Let me know if you want me to clarify anything! — Reply to this email directly, view it on GitHub <#343 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN2PC7K4JXK7LMUL2XKOADXWW5V5ANCNFSM6AAAAAA3UZN3DA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cerebis]

Weighted graphs

Looking at the research code for simulate, I noticed that weighted input graphs are not supported.

Going back over your manuscript, I see that weighted graphs are mentioned as a possibility.

Forgive the question, but how would one properly incorporate the weights from the original graph?

Consider this hack of including the original WEIGHT (my temporary variable name) on line 215 of main.rs. Here I am just assuming that the encoding will effectively scale the original weights, but I expect this is too naive or would come with preconditions I have not met here.

Snippet lines 209..215:

    for (source, row) in links.iter().enumerate() {
        for (target, &weight) in row.iter().enumerate() {
            if weight > 0 {
                let flow = weight as f64 / n_samples as f64;
                let degree = degree[source] as f64 / tot_degree as f64;

                writeln!(f, "{} {} {}", source, target, flow * degree * WEIGHT)?;
            }
        }
    }

Multi-layered graph

Would this work for a two-layer system? I thought perhaps encoding on a single-layer graph, then adding a second layer. Or perhaps encoding on each single-layer graph prior to combining.

[cerebis]

Last post, as I have to move on at present.

Would the correct approach to supporting weighted input graphs be to replace the current uniform random selection of target nodes within the simulate_x() methods (eg choose()) with an alternative that supports weights per element?

I was thinking of random_choice::random_choice()