> > On 27. Feb 2020, at 14:01, Tiago de Paula Peixoto <[email protected]> wrote: > > Am 27.02.20 um 10:19 schrieb Felix Victor Münch: >> For the first version I needed 400-500GB RAM, so that wouldn't be >> overkill. The threads however seem pretty much useless, indeed. > > 500 GB for a network with 3M edges seems absurd. You should be able to > do it with an order of magnitude less memory, at least.
Yes, you’re absolutely right, sorry. It was > 60 million edges in my case. My bad for not reading closely enough (and not having provided that information in this thread before). > >> Hoiweveriwever, as the latter version seems so much more memory >> efficient, I am wondering why it's not implemented as the default in >> form of a function call with the same prominence in the documentation. >> Would love to hear Tiago or anyone else chime in on this. What's the >> advantage of the boiler-plate minimize_nested_blockmodel? Is there any >> except less lines of code? > > The algorithms are not the same, and incur different trade-offs. > > The one in minimize_nested_blockmodel_dl() attempts to bracket the model > complexity with a one-dimensional bisection search, and requires more > memory because it needs to keep several copies of the global state > during the search. > > On the other hand, multiflip_mcmc_sweep() implements merge-split moves, > and keeps only a single state around, hence the improved memory usage. > > Although it depends on the network, minimize_nested_blockmodel_dl() > tends to find better estimates of the ground state (i.e. solutions with > smallest description length) in a shorter time, for a cost of higher > memory usage. > > The next version of the library will include an improved version of > multiflip_mcmc_sweep() that I am preparing, and this alternative will > gain prominence in the documentation. Looking forward to test it. Thanks for the explanation! _______________________________________________ graph-tool mailing list [email protected] https://lists.skewed.de/mailman/listinfo/graph-tool
