[graph-tool] Re: Extra levels created by minimize_nested_blockmodel_dl
Am 16.08.22 um 15:42 schrieb Kevin Reuning: Hello, I am estimating a nested_block_model with bipartite data and am getting a strange result. There are about 4,000 nodes in the network and I am estimating a model by: ``` state_dc = minimize_nested_blockmodel_dl(G, state_args=dict(deg_corr=True, clabel=bipart.a, pclabel=bipart.a, recs=[G.ep.weight], rec_types=["discrete-poisson"])) for i in range(1000): # this should be sufficiently large state_dc.multiflip_mcmc_sweep(beta=np.inf, niter=10) ``` The results find 13 nested levels, but after level 5 there are only 2 nonempty blocks found in each additional level. I'm not sure if this is really a problem, or I can just ignore the levels where nothing really changes. Any advice/help would be greatly appreciated. Thank you If you pass a bipartite pclabel, then this bi-partition gets reflected in the upper levels of the hierarchy as well. This is normal. -- Tiago de Paula Peixoto OpenPGP_signature Description: OpenPGP digital signature ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] Re: Calling node predicates while calculating subgraph_isomorphism?
Am 03.08.22 um 12:50 schrieb Sergey Mironov: Hi. I'm interested in finding subgraph isomorphisms on graphs representing tensor networks. Nodes of such graphs contain expressions (but here one could think of arithmetic expressions over +-/* and variables). Let's say I want to find an isomorphism between my graph and a pattern graph, which contains more generic expressions. Comparing expressions directly doesn't make much sense because of variables, so some form of unification[1] should be used instead. What strategy could I use to fit the existing API of subgraph_isomorphism which currently only allows me to calculate some fixed labels for nodes? The simplest strategy would be for you to define a hash function that maps your arithmetic expressions to integers. You need only to make sure that no collisions exist, but that should be very easy to enforce. The simplest way to do this is to list all the different expressions in all nodes in arbitrary order, and use the order index as a hash value. Is it hard(feasible) to modify the API by adding some form of predicate comparison of nodes? It is feasible, but such an API would be extremely slow, since this predicate would need to be computed in the inner loop of the algorithm. The hash approach outlined above is far faster, and easy to implement in general. Best, Tiago -- Tiago de Paula Peixoto OpenPGP_signature Description: OpenPGP digital signature ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
