GithubHelp home page GithubHelp logo

sbromberger / simpleweightedgraphs.jl Goto Github PK

View Code? Open in Web Editor NEW
49.0 5.0 22.0 96 KB

Simple weighted graphs. Requires LightGraphs.jl.

License: Other

Julia 100.00%
lightgraphs weighted-edges weighted-graphs julia graph

simpleweightedgraphs.jl's Introduction

SimpleWeightedGraphs

Build Status codecov.io

Project Status: As of 8 October 2021 SimpleWeightedGraphs is no longer under active development. It will remain available on Github at sbromberger/SimpleWeightedGraphs.jl. The JuliaGraphs organization will continue to maintain packages that use SimpleWeightedGraphs and transition development over the long term.

Edge-Weighted Graphs for LightGraphs.jl.

Usage:

using LightGraphs, SimpleWeightedGraphs

g = SimpleWeightedGraph(3)  # or use `SimpleWeightedDiGraph` for directed graphs
add_edge!(g, 1, 2, 0.5)
add_edge!(g, 2, 3, 0.8)
add_edge!(g, 1, 3, 2.0)

# find the shortest path from vertex 1 to vertex 3 taking weights into account.
enumerate_paths(dijkstra_shortest_paths(g, 1), 3)
3-element Array{Int64,1}:
 1
 2
 3

# reweight the edge from 1 to 2
add_edge!(g, 1, 2, 1.6)

# rerun the shortest path calculation from 1 to 3
enumerate_paths(dijkstra_shortest_paths(g, 1), 3)
2-element Array{Int64,1}:
 1
 3

# it's possible to build the graph from arrays of sources, destinations and weights
sources = [1,2,1]
destinations = [2,3,3]
weights = [0.5, 0.8, 2.0]
g = SimpleWeightedGraph(sources, destinations, weights)

# the combine keyword handles repeated pairs (sum by default)
g = SimpleWeightedGraph([1,2,1], [2,1,2], [1,1,1]; combine = +)
g.weights[2,1] == g.weights[1,2] == 3 # true

# WARNING: unexpected results might occur with non-associative combine functions

# notice that weights are indexed by [destination, source]
s = SimpleWeightedDiGraph([1,2,1], [2,1,2], [1,1,1]; combine = +)
s.weights[1,2] == 1 # true
s.weights[2,1] == 2 # true

Please pay attention to the fact that zero-weight edges are discarded by add_edge!. This is due to the way the graph is stored (a sparse matrix). A possible workaround is to set a very small weight instead.

Note that adding or removing vertices or edges from these graph types is not particularly performant; see MetaGraphs.jl for possible alternatives.

simpleweightedgraphs.jl's People

Contributors

anandijain avatar bubblingoak avatar dourouc05 avatar ilyaorson avatar joseortiz3 avatar matbesancon avatar oxinabox avatar piever avatar ranjanan avatar sbromberger avatar scheidan avatar timholy avatar vpetukhov avatar willow-ahrens avatar yuehhua avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

simpleweightedgraphs.jl's Issues

Cartesian products are not extended to SimpleWeightedGraphs

When constructing a more complex graph that is logically represented as a cartesian product of two (or more) other graphs, it can be useful to use cartesian_product to simplify the code; however this function produces an illogical result for SimpleWeightedGraphs. Namely, it produces a graph with the correct structure, but with all weights set to 1.0. This seems like very non-ideal and confusing behavior. The cartesian_product function seems easily extendible to weighted graphs, but at the very least I'd think this should throw a warning/error.

As an example,

g = SimpleWeightedGraph(5);
add_edge!(g, 1, 2, 1.0);
add_edge!(g, 1, 3, 1.0);
add_edge!(g, 1, 4, 0.5);
add_edge!(g, 1, 5, 0.5);
 
h = SimpleWeightedGraph(3);
add_edge!(h, 1, 2, 9.0);
add_edge!(h, 2, 3, 1.1);
add_edge!(h, 3, 1, 2.0);

# Produces a {15,27} undirected simple Int64 graph with Float64 weights, but the weights are all 1.0
cartesian_product(g,h)

Running the sample code in the usage section throws an error : not implemented: outneighbours

I've been using LightGraphs for my work and I found this package too useful. But, I've encountered an error when I try and run the sample code listed in the usage section. The error appears when I try to run the command dijkstra_shortest_paths(g, 1). This appears to be the stacktrace

ERROR: Not implemented: outneighbors
Stacktrace:
 [1] #dijkstra_shortest_paths#111(::Bool, ::Bool, ::Function, ::SimpleWeightedGraphs.SimpleWeightedGraph{Int64,Float64}, ::Array{Int64,1}, ::SparseMatrixCSC{Float64,Int64}) at /home/user/.julia/v0.6/LightGraphs/src/shortestpaths/dijkstra.jl:60
 [2] (::LightGraphs.#kw##dijkstra_shortest_paths)(::Array{Any,1}, ::LightGraphs.#dijkstra_shortest_paths, ::SimpleWeightedGraphs.SimpleWeightedGraph{Int64,Float64}, ::Array{Int64,1}, ::SparseMatrixCSC{Float64,Int64}) at ./<missing>:0
 [3] dijkstra_shortest_paths(::SimpleWeightedGraphs.SimpleWeightedGraph{Int64,Float64}, ::Int64) at /home/user/.julia/v0.6/LightGraphs/src/shortestpaths/dijkstra.jl:109

distance calculation with a_star fails with SimpleWeightedGraph and SimpleWeightedDiGraph

I was trying to calculate the distance between two nodes using the A* algorithm implemented in LightGraphs. For example

using LightGraphs, SimpleWeightedGraphs
t = SimpleWeightedGraph(3)
add_edge!(t, 1, 2, 0.5)
add_edge!(t, 2, 3, 0.8)
add_edge!(t, 1, 3, 2.0)
a_star(t, 1,  3)

throws an error:

MethodError: no method matching SimpleWeightedGraphs.SimpleWeightedEdge{Int64,Float64}(::Int64, ::Int64)

So far I have worked out, that the problem arises, when the a_star algorithm tries to call the constructor of the SimpleWeightedEdge type in the a_start.jl file.
I would have believed that the definition of

SimpleWeightedEdge(x, y) = SimpleWeightedEdge(x, y, one(Float64))

in line 18 of simpleweightededge.jl would exactly match this case. Am I missing something, or is this a bug?

Direction of edges inverted when going from `SimpleWeightedDiGraph` to `SimpleDiGraph`

Hello everyone,

Thanks for your work on SimpleWeightedGraphs.jl~

I recently noticed that converting from a SimpleWeightedDiGraph to a SimpleDiGraph inverts the direction of the edges.

using SimpleWeightedGraphs, LightGraphs

# Create lists of sources and destination vertices
sources = [i for i in 1:3]
destinations = [4 for _ in 1:length(sources)]
weights = [1. for _ in 1:length(sources)]

# Construct the weighted and directed graph
g_weighted = SimpleWeightedDiGraph(sources, destinations, weights)
edge_weights = getfield.(collect(edges(g_weighted)), :weight)

# Convert the weighted graph to a simple directed graph
g_directed = SimpleDiGraph(g_weighted)

However:

julia> collect(edges(g_weighted))
3-element Array{SimpleWeightedEdge{Int64,Float64},1}:
 Edge 1 => 4 with weight 1.0
 Edge 2 => 4 with weight 1.0
 Edge 3 => 4 with weight 1.0

and

julia> collect(edges(g_directed))
3-element Array{LightGraphs.SimpleGraphs.SimpleEdge{Int64},1}:
 Edge 4 => 1
 Edge 4 => 2
 Edge 4 => 3

Of course this is easily fixed by doing reverse(g_directed), but it is confusing nevertheless.

Thanks!

Support for complex weights

I think support for complex weights would be very beneficial for anyone solving controls problems. I can't seem to tell if there was any justification for only supporting reals.

Ambiguity error on pagerank

Had the following ambiguity error just pop up.

julia> SimpleWeightedGraphs.pagerank(g)
ERROR: MethodError: pagerank(::SimpleWeightedDiGraph{Int64,Float64}, ::Float64, ::Int64, ::Float64) is ambiguous. Candidates:
  pagerank(g::SimpleWeightedDiGraph, α, n, ϵ) in SimpleWeightedGraphs at /Users/zchristensen/.julia/packages/SimpleWeightedGraphs/yU
Frc/src/overrides.jl:22
  pagerank(g::AbstractGraph{U}, α, n::Integer, ϵ) where U<:Integer in LightGraphs at /Users/zchristensen/.julia/packages/LightGraphs
/HsNig/src/centrality/pagerank.jl:21
Possible fix, define
  pagerank(::SimpleWeightedDiGraph{U<:Integer,U} where U<:Real, ::Any, ::Integer, ::Any)
S

Adjacency & Laplacian matrices do not reflect edge weights

I constructed a weighted graph using SimpleWeightedGraphs.jl and tried to get its adjacency and Laplacian matrices via adjacency_matrix(G) and laplacian_matrix(G). However, these matrices are the same as those of the unweighted case (i.e., all the edges have the same weight 1). It would be great if these matrices reflect the edge weights assigned. Or do I need to use some other functions to get proper versions of these matrices? Thanks for your help! Here is my MWE:

# creating a simple unweighted path
G=SimpleGraph(3);
add_edge!(G, 1, 2);
add_edge!(G, 2, 3);
W=Array(adjacency_matrix(G))
3×3 Array{Int64,2}:
 0  1  0
 1  0  1
 0  1  0
L=Array(laplacian_matrix(G))
3×3 Array{Int64,2}:
  1  -1   0
 -1   2  -1
  0  -1   1
# now for a weighted path graph
Gw=SimpleWeightedGraph(3);
add_edge!(Gw, 1, 2, 5.0);
add_edge!(Gw, 2, 3, 10.0);
Ww=Array(adjacency_matrix(Gw))
3×3 Array{Int64,2}:
 0  1  0
 1  0  1
 0  1  0
Lw=Array(laplacian_matrix(Gw))
3×3 Array{Int64,2}:
 1  -1   0
-1   2  -1
 0  -1   1

Of course, I want to have the last two matrices as follows:

Ww
3×3 Array{Float64,2}:
 0.0  5.0  0.0
 5.0  0.0 10.0
 0.0 10.0  0.0
Lw
3×3 Array{Float64,2}:
 5.0  -5.0   0.0
-5.0  15.0 -10.0
 0.0 -10.0  10.0

Why G.weights is the transpose of adjacent_matrix(G)

I just wondering why do we design this.
when I add an edge

add_edge!(G, 1, 3, 0.9)

G.weights is

5×5 SparseArrays.SparseMatrixCSC{Float64,Int64} with 1 stored entry:
  [3, 1]  =  0.9

Sorry if it is not proper to ask question by raising issues.

Error: Non symmetric matrices created by repeated pairs

Hi,

Creating a simpleWeigthedGraph with repeated pairs may raise the error "Adjacency / distance matrices must be symmetric" due to numerical imprecision, even when using + as combine function.

For instance, the sparse matrix constructed when creating the weighted graph using the following data is not symmetric.

sources = [3, 3, 3, 3, 4, 1, 3, 3, 3, 4, 1, 3, 4]
destinations = [2, 4, 1, 1, 1, 4, 4, 2, 4, 2, 2, 1, 3]
weights = [0.22279, 0.287542, 0.461288, 0.222349, 0.838298, 0.295453, 0.995701, 0.878216, 0.0935724, 0.184148, 0.397035, 0.601133, 0.873484]
s = sparse(vcat(sources,destinations), vcat(destinations,sources), vcat(weights,weights),4, 4, +)
println(issymmetric(s))

Hence, g = SimpleWeightedGraph(sources, destinations, weights) raises an error.

Is it possible to find another way to construct the sparse matrix? Or indicate in the doc that repeated pairs should not be used with float weights?

Best,

Removing an edge just sets the edge weight to 0

julia> g = SimpleWeightedGraph(2); add_edge!(g, 1, 2); collect(edges(g))
1-element Array{SimpleWeightedEdge{Int64,Float64},1}:
 Edge 1 => 2 with weight 1.0

julia> rem_edge!(g, 1, 2); collect(edges(g))
1-element Array{SimpleWeightedEdge{Int64,Float64},1}:
 Edge 1 => 2 with weight 0.0

Brief Slack discussion suggests this behavior arises from performance considerations around using sparse matrices; changing a value in a sparse matrix is much faster than changing the sparsity structure. For some use cases, this is totally okay. For example, if edges are "pipes" and edge weights are capacities, then a 0-weight edge and an absent edge are no different.

On the other hand, if edges represent possible movements between locations and edge weights are distances or costs, then a 0-weight edge means something very different than the absence of an edge.

Recommendation on plotting weighted graphs

I want to plot a weighted graph with the edge width proportional to the corresponding edge weight. Is there any good plotting function/package for this? Since I'm familiar with Plots.jl, I want to use it if possible, but Plots.jl functions do not accept LightGraphs/SimpleWeightedGraphs data structure.
Thanks for your help!
BVPs

Doubling the weights of self-edges

I'm trying to construct a weighted graph with self-edges using the SimpleWeightedGraph(srcs, dsts, weights) constructor from here but the weights of self-edges seem to be counted twice. For example

> collect(edges(SimpleWeightedGraph([1],[1],[1])))
1-element Array{SimpleWeightedEdge{Int64,Int64},1}:
 Edge 1 => 1 with weight 2

although the edge 1=>1 was specified only once. This is coming from vcat duplicating [1] into [1,1] for source, destination and the weight ending up in a double self-edge. So currently there is no way to use this constructor to get a self-edge with weight 1 (assuming integer input weights).
I don't know if this was intended, if not it could be fixed with the code below.

d=i.!=j
sparse(vcat(i,j[d]), vcat(j,i[d]), vcat(w,w[d]), m, m, combine)

Neighbors related functions give wrong result after `rem_edge!` because it just set edge weight to 0

Removing an edge just sets the edge weight to 0 #43
Another bug brought by this implementation is that neighbors related functions such as neighbors, inneighbors and outneighbors give wrong result.

julia> g = SimpleWeightedGraph([1 0 ; 0 1])
g {2, 2} undirected simple Int64 graph

julia> inneighbors(g, 2)
Int64[2]

julia> rem_edge!(g, edgetype(g)(2, 2))

julia> inneighbors(g, 2)
Int64[2] # it will be Int64[] if we use SimpleGraph or SimpleDiGraph

It is because we never dropzeros! every time we remove an edge. I think that should be corrected at least when we run neighbors because rem_edge! is explicitly declaring that link is removed so they should no longer be neighbors to each others.

Potential problem with Pagerank for SimpleWeightedDiGraphs

I think there is a problem with the overloaded pagerank function for SimpleWeightedDiGraphs.

Note that if we define the (unweighted) graph based on A = [0 1 1; 1 0 0; 0 1 0], where g = SimpleDiGraph(A), the call pagerank(g)results in something like [0.3878; 0.3974; 0.2148] (which I believe is correct), while the same call on h = SimpleWeightedDiGraph(A) results in [0.3974; 0.3878; 0.2148] (note that the first and second entries are now swapped).

My guess is that the problem is in the second line of the code, where the summation along rows S = vec(sum(A, dims=1)) should be on M (or A transpose, if you like). For truly weighted graphs (unlike the trivial example above), this leads to fairly wacky results.

On an unrelated note (two, actually), this is my first issue on GitHub, so apologies if I am not following the proper etiquette. More importantly, thank you very much for the fantastic effort made in building this (and all related) package(s).

Inconsistent adjacency matrix for weighted and unweighted graphs

We have the correct behaviour (self-edges should be double counted as pointed out in #38)

julia> g = SimpleGraph(1)
{1, 0} undirected simple Int64 graph

julia> add_edge!(g,1, 1)
true

julia> adjacency_matrix(g)

1×1 SparseArrays.SparseMatrixCSC{Int64,Int64} with 1 stored entry:
[1, 1] = 2

but we have the following which is inconsistent

julia> w = SimpleWeightedGraph(1)
{1, 0} undirected simple Int64 graph with Float64 weights

julia> add_edge!(w, 1, 1, 10)
true

julia> adjacency_matrix(w)
1×1 SparseArrays.SparseMatrixCSC{Int64,Int64} with 1 stored entry:
  [1, 1]  =  1

Ideally I would expect to see 20 (which is correct for weighted and undirected graphs) but at the very least I would expect to see 2 and not 1.

Zero-weight edges are ignored

I was debugging things in my code when I noticed that the number of edges that SimpleWeightedGraphs remembered is very low (289 instead of 3198). I found that edges whose weight is zero are simply ignored. Taking the README example:

g = SimpleWeightedGraph(3)
add_edge!(g, 1, 2, 0.5)
add_edge!(g, 2, 3, 0.8)
add_edge!(g, 1, 3, 0.0) # Weight changed to zero

The resulting graph has only two edges:

julia> g
{3, 2} undirected simple Int64 graph with Float64 weights

julia> collect(edges(g))
2-element Array{SimpleWeightedGraphs.SimpleWeightedEdge{Int64,Float64},1}:
 Edge 1 => 2 with weight 0.5
 Edge 2 => 3 with weight 0.8

Is this behaviour expected? To say the least, I would say not… Is it documented anywhere? Would it be possible to add a warning in add_edge! when the weight is zero (before it gets fixed)?

Performance issue while adding edges

I tried running the example in README.md but Julia v0.6 gave a warning:

julia> add_edge!(g, 1, 2, 0.5)
WARNING: Note: adding edges to this graph type is not performant.
true

ProfileView showed type instability for the add_edge! method.

using LightGraphs, SimpleWeightedGraphs, ProfileView

function f()
    g = SimpleWeightedGraph()
    for i in 1:1000
        add_vertex!(g)
        add_edge!(g,1,i,0.2)
    end
    g
end

f();
Profile.clear()
@profile f()
ProfileView.view()

Am I doing something wrong here?
I need a performant weighted undirected graph for my work.

gplot(::SimpleWeightedGraph) not working

Hello, is plotting supposed to work?

julia> gplot(G)
ERROR: MethodError: no method matching _src_index(::SimpleWeightedEdge{Int64,Float64}, ::SimpleWeightedGraph{Int64,Float64})```

Weighted `degree`

Would a weighted implementation of degree be a welcome contribution here? I assume overloading degree would be the best approach.

`ne` fails to count the correct number of self-edges

Hi! This is my first ever contribution to someone else's package on GiiHub so please bear with me :)

I've noticed the following:

julia> test = SimpleWeightedGraph(CompleteGraph(3))
{3, 3} undirected simple Int64 graph with Float64 weights

julia> ne(test)
3

julia> add_edge!(test, 1, 1, 10)
true

julia> ne(t)
3

The reason is simply the definition here is not meant to be used with self loops; it only works because non-self loops are double counted. I propose that

ne(g::SimpleWeightedGraph) = nnz(g.weights) ÷ 2

be changed to

ne(g::SimpleWeightedGraph) = nnz(triu(g.weights))

However, such a change breaks 3 of the test (I don't really understand why). When I run julia runtests.jl the output is

[ Info: Ignore warnings relating to adding and removing vertices and edges
┌ Warning: Note: adding edges with a zero weight to this graph type has no effect.
└ @ SimpleWeightedGraphs ~/.julia/packages/SimpleWeightedGraphs/yUFrc/src/simpleweightedgraph.jl:103
┌ Warning: Note: adding edges with a zero weight to this graph type has no effect.
└ @ SimpleWeightedGraphs ~/.julia/packages/SimpleWeightedGraphs/yUFrc/src/simpleweighteddigraph.jl:88
Overrides: Test Failed at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21
  Expression: (weights(cartesian_product(g3, gz)))[11, 12] == (weights(gz))[3, 4]
   Evaluated: 1.0 == 87.0
Stacktrace:
 [1] macro expansion at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21 [inlined]
 [2] macro expansion at /home/user/Documents/julia/usr/share/julia/stdlib/v1.0/Test/src/Test.jl:1083 [inlined]
 [3] top-level scope at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:2
Overrides: Test Failed at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21
  Expression: (weights(cartesian_product(g3, gz)))[11, 12] == (weights(gz))[3, 4]
   Evaluated: 1.0 == 87.0
Stacktrace:
 [1] macro expansion at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21 [inlined]
 [2] macro expansion at /home/user/Documents/julia/usr/share/julia/stdlib/v1.0/Test/src/Test.jl:1083 [inlined]
 [3] top-level scope at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:2
Overrides: Test Failed at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21
  Expression: (weights(cartesian_product(g3, gz)))[11, 12] == (weights(gz))[3, 4]
   Evaluated: 1.0 == 87.0
Stacktrace:
 [1] macro expansion at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:21 [inlined]
 [2] macro expansion at /home/user/Documents/julia/usr/share/julia/stdlib/v1.0/Test/src/Test.jl:1083 [inlined]
 [3] top-level scope at /home/user/Documents/SimpleWeightedGraphs.jl/test/overrides.jl:2
┌ Warning: Saving compressed graphs is no longer supported in LightGraphs. Use `LGCompressedFormat()` from the `GraphIO.jl` package instead. Saving uncompressed.
│   caller = ip:0x0
└ @ Core :-1
┌ Warning: Saving compressed graphs is no longer supported in LightGraphs. Use `LGCompressedFormat()` from the `GraphIO.jl` package instead. Saving uncompressed.
│   caller = savegraph(::String, ::SimpleWeightedGraph{Int64,Float64}) at overrides.jl:56
└ @ SimpleWeightedGraphs ~/.julia/packages/SimpleWeightedGraphs/yUFrc/src/overrides.jl:56
Test Summary:          | Pass  Fail  Total
SimpleWeightedGraphs   |  349     3    352
  SimpleWeightedEdge   |   27           27
  SimpleWeightedGraphs |  251          251
  Overrides            |   48     3     51
  Persistence          |   14           14
  Connectivity         |    9            9
ERROR: LoadError: Some tests did not pass: 349 passed, 3 failed, 0 errored, 0 broken.
in expression starting at /home/user/Documents/SimpleWeightedGraphs.jl/test/runtests.jl:21

Ideas?

function inneighbors does not work on directed weighted graphs

using LightGraphs, SimpleWeightedGraphs
g = SimpleWeightedDiGraph(3)
inneighbors(g, 3)

> ERROR: type Adjoint has no field rowval
Stacktrace:
 [1] getproperty(::Any, ::Symbol) at ./sysimg.jl:18
 [2] inneighbors(::SimpleWeightedDiGraph{Int64,Float64}, ::Int64) at /home/simon/.julia/dev/SimpleWeightedGraphs/src/simpleweighteddigraph.jl:86
 [3] top-level scope at none:0

Using Julia 0.7 (nightly)
outneighbors(g, 3) seems to work though.

Induced subgraph

LightGraphs and MetaGraphs have the nice feature of selecting a subgraph through convenient slicing:

julia> using LightGraphs, MetaGraphs, Random
julia> Random.seed!(1234)
julia> G = erdos_renyi(100, 50)
{100, 50} undirected simple Int64 graph
julia> G[1:10]
{10, 1} undirected simple Int64 graph

julia> Gm = MetaGraph(G)
julia> Gm[1:10]
{10, 1} undirected Int64 metagraph with Float64 weights defined by :weight (default weight 1.0)

However, this seems to be not yet supported in SimpleWeightedGraphs:

julia> using SimpleWeightedGraphs
julia> Gw = SimpleWeightedGraph(G)
julia> Gw[1:10]

ERROR: MethodError: no method matching SimpleWeightedEdge{Int64,Float64}(::LightGraphs.SimpleGraphs.SimpleEdge{Int64})
Closest candidates are:
  SimpleWeightedEdge{Int64,Float64}(::Any, ::Any, ::Any) where {T<:Integer, U<:Real} at /mnt/gaia/janko/.julia/packages/SimpleWeightedGraphs/diCGL/src/simpleweightededge.jl:7
  SimpleWeightedEdge{Int64,Float64}(::Pair) where {U<:Real, T<:Integer} at /mnt/gaia/janko/.julia/packages/SimpleWeightedGraphs/diCGL/src/simpleweightededge.jl:15
  SimpleWeightedEdge{Int64,Float64}(::Tuple{T,T} where T) where {U<:Real, T<:Integer} at /mnt/gaia/janko/.julia/packages/SimpleWeightedGraphs/diCGL/src/simpleweightededge.jl:17
  ...
Stacktrace:
 [1] add_edge!(::SimpleWeightedGraph{Int64,Float64}, ::LightGraphs.SimpleGraphs.SimpleEdge{Int64}) at /mnt/gaia/janko/.julia/packages/SimpleWeightedGraphs/diCGL/src/SimpleWeightedGraphs.jl:73
 [2] induced_subgraph(::SimpleWeightedGraph{Int64,Float64}, ::UnitRange{Int64}) at /mnt/gaia/janko/.julia/packages/LightGraphs/PPsyP/src/operators.jl:506
 [3] getindex(::SimpleWeightedGraph{Int64,Float64}, ::UnitRange{Int64}) at /mnt/gaia/janko/.julia/packages/LightGraphs/PPsyP/src/operators.jl:540
 [4] top-level scope at none:0

Would it be possible to add this helpful behaviour?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.