juliagraphs / staticgraphs.jl

Memory-efficient immutable LightGraphs.

StaticGraphs

Memory-efficient, performant graph structures optimized for large networks. Uses Graphs.

Note: adding/removing edges and vertices is not supported with this graph type.

staticgraphs.jl's Issues

Documentation on Building a StaticGraph

I would love documentation on how to build a StaticGraph from scratch. The constructor is quite intimidating.

unsafeview will segfault in 0.7

That’ll lead to segfaults on 0.7 because the GC might collect the array out from underneath you

Should replace with https://github.com/oschulz/UnsafeArrays.jl.

Type-unsafe constructors

I'm not a fan of these constructors (same for StaticDigraph)

function StaticGraph(n_v, ss::AbstractVector, ds::AbstractVector)

They don't specify an element type for ss and ds, and then need to use convert(Vector{T},ds) with T as the smallest type to contain them:

function mintype(v::AbstractVector)
    validtypes = [UInt8, UInt16, UInt32, UInt64, UInt128]
    l = v[end]
    for T in validtypes
        l <= typemax(T) && return T
    end
    return eltype(v)
end

Shouldn't the input vectors directly specify a type?

StaticGraphs with edge properties

Hi,
for the kind of stuff we do in my research group (inference on graphs, message-passing algorithms) it would be great to have a graph library where one can store edge properties efficiently. For example we need to save for each edge a message in the form of a Vector{Float64}, then loop over messages incoming to a certain node.

The currently available options seem to be:

• MetaGraphs.jl: properties are stored using Dicts, which is not very efficient nor elegant
• SimpleWeightedGraphs.jl: for each edge one can store a 'weight', which is constrained to be <:Real, while it would be useful to have it more generic. Moreover, weights are stored as elements of a SparseMatrixCSC meaning that setting a weight to zero will cause the edge to disappear (!)

One solution would be to assign an index 1,2,...,Nedges to each edge. This way one can keep edge properties (of any type) in a separate vector, indexed by the edge index.
This requires a new type of edge which stores an index in addition to the usual source and destination fields. Something on the lines of

struct SimpleEdgeIndexed{T<:Integer} <: AbstractSimpleEdge{T}
    src::T
    dst::T
    idx::T
end

instead of the StaticEdge you mutuate from SimpleGraphs. Everything else should more or less stay the same.

Do you think this makes sense? If so i can try and write it properly and do a PR.

adjacency_matrix mismatch with LG definition

Re-write LG.adjacency_matrix to match the LG definition

need induced_subgraph

julia> g[1:3]
{3, 2} directed simple Int64 graph

julia> d1[1:3]
ERROR: MethodError: no method matching StaticDiGraph{UInt8,UInt8}(::Int64)
Closest candidates are:
  StaticDiGraph{UInt8,UInt8}(::Any, ::Any, ::Any, ::Any) where {T<:Integer, U<:Integer} at /Users/bromberger1/.julia/dev/StaticGraphs/src/staticdigraph.jl:7
  StaticDiGraph{UInt8,UInt8}(::StaticDiGraph) where {U<:Integer, T<:Integer} at /Users/bromberger1/.julia/dev/StaticGraphs/src/staticdigraph.jl:67
Stacktrace:
 [1] induced_subgraph(::StaticDiGraph{UInt8,UInt8}, ::UnitRange{Int64}) at /Users/bromberger1/.julia/dev/LightGraphs/src/operators.jl:492
 [2] getindex(::StaticDiGraph{UInt8,UInt8}, ::UnitRange{Int64}) at /Users/bromberger1/.julia/dev/LightGraphs/src/operators.jl:540
 [3] top-level scope at none:0

JLD2 compat

Can the JLD2 compat be bumped to include 0.2, 0.3, 0.4?

collect(edges(g::StaticDiGraph)) doesn't work.

julia> g
{4, 3} directed simple static {UInt8, UInt8} graph

julia> collect(edges(g))
ERROR: type StaticDiGraph has no field fadjlist
Stacktrace:
 [1] getproperty(::StaticDiGraph{UInt8,UInt8}, ::Symbol) at ./Base.jl:20
 [2] fadj(::StaticDiGraph{UInt8,UInt8}) at /home/seth/.julia/dev/LightGraphs/src/SimpleGraphs/SimpleGraphs.jl:78
 [3] macro expansion at /home/seth/.julia/dev/LightGraphs/src/SimpleGraphs/simpleedgeiter.jl:59 [inlined]
 [4] iterate at /home/seth/.julia/packages/SimpleTraits/7CF63/src/SimpleTraits.jl:325 [inlined]
 [5] iterate at /home/seth/.julia/packages/SimpleTraits/7CF63/src/SimpleTraits.jl:350 [inlined] (repeats 2 times)
 [6] copyto!(::Array{LightGraphs.SimpleGraphs.SimpleEdge{UInt8},1}, ::LightGraphs.SimpleGraphs.SimpleEdgeIter{StaticDiGraph{UInt8,UInt8}}) at ./abstractarray.jl:722
 [7] _collect(::UnitRange{Int64}, ::LightGraphs.SimpleGraphs.SimpleEdgeIter{StaticDiGraph{UInt8,UInt8}}, ::Base.HasEltype, ::Base.HasLength) at ./array.jl:566
 [8] collect(::LightGraphs.SimpleGraphs.SimpleEdgeIter{StaticDiGraph{UInt8,UInt8}}) at ./array.jl:560
 [9] top-level scope at REPL[19]:1

`neighbors` segfaults on large out of bounds indices

Trying to run neighbors on a StaticDiGraph using a sufficiently large out-of-bounds index results in a segfault.

Reproducible Example:

using Graphs
using StaticGraphs
g = SimpleDiGraph([0 1 1; 0 0 1; 0 0 0])
gg = StaticDiGraph(g)
neighbors(gg, 256222222)

Results in:

signal (11): Segmentation fault
in expression starting at REPL[14]:1
unitrange_last at ./range.jl:359 [inlined]
UnitRange at ./range.jl:354 [inlined]
Colon at ./range.jl:5 [inlined]
Colon at ./range.jl:3 [inlined]
_fvrange at /home/aayush/.julia/packages/StaticGraphs/l0WpK/src/StaticGraphs.jl:67 [inlined]
fadj at /home/aayush/.julia/packages/StaticGraphs/l0WpK/src/StaticGraphs.jl:71 [inlined]
outneighbors at /home/aayush/.julia/packages/StaticGraphs/l0WpK/src/StaticGraphs.jl:89 [inlined]
neighbors at /home/aayush/.julia/packages/Graphs/Mih78/src/core.jl:242
unknown function (ip: 0x7f63f36ba343)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2247 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2429
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1788 [inlined]
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:126
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:215
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:166 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:587
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:731
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:885
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:830
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:830
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/toplevel.c:944
eval at ./boot.jl:373 [inlined]
eval_user_input at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:150
repl_backend_loop at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:244
start_repl_backend at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:229
#run_repl#47 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:362
run_repl at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:349
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2247 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2429
#930 at ./client.jl:394
jfptr_YY.930_31132 at /home/aayush/.julia/sysimages/ohmyrepl.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2247 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2429
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1788 [inlined]
jl_f__call_latest at /buildworker/worker/package_linux64/build/src/builtins.c:757
#invokelatest#2 at ./essentials.jl:716 [inlined]
invokelatest at ./essentials.jl:714 [inlined]
run_main_repl at ./client.jl:379
exec_options at ./client.jl:309
_start at ./client.jl:495
jfptr__start_38971 at /home/aayush/.julia/sysimages/ohmyrepl.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2247 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2429
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1788 [inlined]
true_main at /buildworker/worker/package_linux64/build/src/jlapi.c:559
jl_repl_entrypoint at /buildworker/worker/package_linux64/build/src/jlapi.c:701
main at julia (unknown line)
__libc_start_main at /usr/lib/libc.so.6 (unknown line)
unknown function (ip: 0x400808)
Allocations: 9459103 (Pool: 9455476; Big: 3627); GC: 8

AbstractStaticGraph type parameters

It should be writter in the docstring of AbstractStaticGraph what T and U are, for now we have to look at other methods

we can improve adjacency_matrix

for StaticGraphs:

adjacency_matrix(g) = SparseMatrixCSC{Bool,UInt32}(nv(g), nv(g), g.f_ind, g.f_vec, ones(Bool, ne(g)*2));

for StaticDiGraphs, just remove the *2.

New version for compatibility changes

Hi @sbromberger, please can you release a new version of the package so the compat changes are available in the general registry? Can do a PR with the version bump if you like - let me know. Cheers!

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

No default constructor

There is no default constructor for a StaticGraph

julia> using StaticGraphs

julia> StaticGraph()
ERROR: MethodError: no method matching StaticGraphs.StaticGraph()
Closest candidates are:
  StaticGraphs.StaticGraph(::Array{T<:Integer,1}, ::Array{T<:Integer,1}) where T<:Integer at ~/.julia/v0.6/StaticGraphs/src/staticgraph.jl:9
  StaticGraphs.StaticGraph(::LightGraphs.SimpleGraphs.SimpleGraph) at ~/.julia/v0.6/StaticGraphs/src/staticgraph.jl:36
  StaticGraphs.StaticGraph(::Any, ::Array{T<:Integer,1}, ::Array{T<:Integer,1}) where T<:Integer at ~/.julia/v0.6/StaticGraphs/src/staticgraph.jl:21
  ...

Finished or abandoned

Is this ready for production, and simply finished, since it relays much on the Graphs package anyway?
Or is this simply abandoned?

In the latter case, is it possible to archive a repo, so this becomes less ambiguous. :)

Register v0.2.0

@JuliaRegistrator register