poisotlab / brim.jl Goto Github PK

Not really sure it is the case at the moment...

Ends up with lines full of 0 sometimes

As described in https://discourse.julialang.org/t/ann-plans-for-removing-packages-that-do-not-yet-support-1-0-from-the-general-registry/ we are planning on removing packages that do not support 1.0 from the General registry. This package has been detected to not support 1.0 and is thus slated to be removed. The removal of packages from the registry will happen approximately a month after this issue is open.

To transition to the new Pkg system using Project.toml, see https://github.com/JuliaRegistries/Registrator.jl#transitioning-from-require-to-projecttoml.
To then tag a new version of the package, see https://github.com/JuliaRegistries/Registrator.jl#via-the-github-app.

If you believe this package has erroneously been detected as not supporting 1.0 or have any other questions, don't hesitate to discuss it here or in the thread linked at the top of this post.

See JuliaLang/METADATA.jl#3769; we're about to make Color uninstallable on julia 0.4.

Transition info is here.

• write docstrings for all (exported) functions
• move README to a doc page
• use mkdocs to wrap it all
• update the pages in the User guide section

On some networks (Kato et al. 1990 has to be one of the worse in ecology), large size + low connectance means that a lot of tentative runs are discarded (because not swapable).

This means that logging every 1000 events could generate GBs of log in a short time. One possibility would be to log every 2 minutes or so, using call to time. It may add a bit of overhead, but nothing compared to the overall randomization loop.

Currently there are two very similar inbound loops in label_propagation
-- these should be rewritten as a single function

Example (data size within the order of magnitude of the gene set problem)

A = map((x) -> x<=0.01?1:0, rand((1000, 10000)))
A |> partition_random |> recursive_brim! |> Q

Run time less important that memory footprint

As of now, the tests generate a random network, which (sometimes) can take a lot of time to swap. It would be better to either

• use a perfectly nested or perfectly modular known network
• use an empirical example

Should be easy enough -- just get the adjacency matrix from the graph using built-in functions