Coder Social home page Coder Social logo

juliagraphs / graphs.jl Goto Github PK

View Code? Open in Web Editor NEW
444.0 14.0 87.0 15.07 MB

An optimized graphs package for the Julia programming language

Home Page: http://juliagraphs.org/Graphs.jl/

License: Other

Julia 100.00%
juliagraphs julia graphs graph graph-algorithms graph-analytics graph-theory data-structures datastructures hacktoberfest

graphs.jl's Introduction

Graphs.jl

Documentation stable Documentation dev Build status Code coverage Code style: Blue Aqua QA ColPrac: Contributor's Guide on Collaborative Practices for Community Packages

Overview

The goal of Graphs.jl is to offer a performant platform for network and graph analysis in Julia, following the example of libraries such as NetworkX in Python. To this end, Graphs.jl offers:

  • a set of simple, concrete graph implementations -- SimpleGraph (for undirected graphs) and SimpleDiGraph (for directed graphs)
  • an API for the development of more sophisticated graph implementations under the AbstractGraph type
  • a large collection of graph algorithms with the same requirements as this API.

Installation

Installation is straightforward. First, enter Pkg mode by hitting ], and then run the following command:

pkg> add Graphs

Basic use

Graphs.jl includes numerous convenience functions for generating graphs, such as path_graph, which builds a simple undirected path graph of a given length. Once created, these graphs can be easily interrogated and modified.

julia> g = path_graph(6)
{6, 5} undirected simple Int64 graph

# Number of vertices
julia> nv(g)
6

# Number of edges
julia> ne(g)
5

# Add an edge to make the path a loop
julia> add_edge!(g, 1, 6);

Documentation

The full documentation is available at GitHub Pages. Documentation for methods is also available via the Julia REPL help system. Additional tutorials can be found at JuliaGraphsTutorials.

Citing

We encourage you to cite our work if you have used our libraries, tools or datasets. Starring the Graphs.jl repository on GitHub is also appreciated.

The latest citation information may be found in the CITATION.bib file within the repository.

Contributing

We welcome contributions and bug reports! Please see CONTRIBUTING.md for guidance on development and bug reporting.

JuliaGraphs development subscribes to the Julia Community Standards.

Related packages

It is an explicit design decision that any data not required for graph manipulation (attributes and other information, for example) is expected to be stored outside of the graph structure itself.

Additional functionality like advanced IO and file formats, weighted graphs, property graphs, and optimization-related functions can be found in the packages of the JuliaGraphs organization.

Project status

The Graphs.jl project is a reboot of the LightGraphs.jl package (archived in October 2021), which remains available on GitHub at sbromberger/LightGraphs.jl. If you don't need any new features developed since the fork, you can continue to use older versions of LightGraphs.jl indefinitely. New versions will be released here using the name Graphs.jl instead of LightGraphs.jl. There was an older package also called Graphs.jl. The source history and versions are still available in this repository, but the current code base is unrelated to the old Graphs.jl code and is derived purely from LightGraphs.jl. To access the history of the old Graphs.jl code, you can start from commit 9a25019.

Transition from LightGraphs to Graphs

LightGraphs.jl and Graphs.jl are functionally identical, still there are some steps involved making the change:

  • Change LightGraphs = "093fc24a-ae57-5d10-9952-331d41423f4d" to Graphs = "86223c79-3864-5bf0-83f7-82e725a168b6" in your Project.toml.
  • Update your using and import statements.
  • Update your type constraints and other references to LightGraphs to Graphs.
  • Increment your version number. Following semantic versioning, we suggest a patch release when no graphs or other Graphs.jl-objects can be passed through the API of your package by those depending on it, otherwise consider it a breaking release. "Passed through" entails created outside and consumed inside your package and vice versa.
  • Tag a release.

About versions

  • The master branch of Graphs.jl is generally designed to work with versions of Julia starting from the LTS release all the way to the current stable release, except during Julia version increments as we transition to the new version.
  • Later versions: Some functionality might not work with prerelease / unstable / nightly versions of Julia. If you run into a problem, please file an issue.
  • The project was previously developed under the name LightGraphs.jl and older versions of LightGraphs.jl (≤ v1.3.5) must still be used with that name.
  • There was also an older package also called Graphs.jl (git tags v0.2.5 through v0.10.3), but the current code base here is a fork of LightGraphs.jl v1.3.5.
  • All older LightGraphs.jl versions are tagged using the naming scheme lg-vX.Y.Z rather than plain vX.Y.Z, which is used for old Graphs.jl versions (≤ v0.10) and newer versions derived from LightGraphs.jl but released with the Graphs.jl name (≥ v1.4).
  • If you are using a version of Julia prior to 1.x, then you should use LightGraphs.jl at lg-v.12.* or Graphs.jl at v0.10.3

graphs.jl's People

Contributors

abhinavmehndiratta avatar afternone avatar alainlich avatar athulappadan avatar aurorarossi avatar azzaare avatar carlolucibello avatar dehann avatar deinst avatar etiennedeg avatar gdalle avatar iainnz avatar johnmyleswhite avatar jpfairbanks avatar juliohm avatar keno avatar kshyatt avatar lindahua avatar matbesancon avatar mlubin avatar mschauer avatar nfoti avatar pozorvlak avatar pranavtbhat avatar rsofaer avatar sbromberger avatar simonschoelly avatar sohamtamba avatar tkelman avatar viralbshah 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  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  avatar  avatar

Watchers

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

graphs.jl's Issues

`is_cyclic` for undirected graphs

Issue previously open at #1518 for LightGraphs.jl.

The is_cyclic function in LightGraphs.jl works well for directed graphs but for undirected graphs returns true for any nonempty graph. The usual definition for undirected graphs is that cycles don't contain repeated links, so 1->2->1 is not considered a cycle (absent multiple edges.)

Useful for me because I want a function that will test whether an (undirected) network is a tree and easiest way to check that is to confirm the graph is acyclic+connected

[BUG] `biconnected_components` loses some edges - should we return only vertices ?

This is a repost of this issue, I think it deserves discussion on whether we should return edges instead of vertices.

Summary :

start=[1,1,2,2,2,3,4,4,5,5,7,7,8,8,9,9,10,10,12,12,1,2,3]
destination=[2,4,4,5,3,5,7,8,7,8,9,10,9,10,11,12,12,13,13,11,11,12,13]

graph_s=SimpleWeightedGraph(start,destination,collect(1:23))

bi_components= biconnected_components(graph_s)

graph_s has 23 edges, but only 19 are returned in the unique biconnected component.

etienneINSA : The error is here : the edge is added only if state.low[v] > state.depth[w], whereas it should be always added to the stack. I can make a PR, but I have an interrogation: Why do we return the biconnected components by their edges? As the subgraphs are induced, this is more easily defined by the vertices. Is there a good reason to do that, or would it be too breaking to change this behavior?

Non-deterministic test failure in closness centrality

I saw this once on my mac running single threaded

 Testing Running tests...
Parallel.Closeness: Test Failed at /Users/viral/.julia/packages/Graphs/mjncd/test/parallel/centrality/closeness.jl:14
  Expression: tz ≈ [0.75, 0.4444444444444444, 0.3333333333333333, 0.0]
   Evaluated: [0.75, 0.4444444444444444, 0.3333333333333333, NaN] ≈ [0.75, 0.4444444444444444, 0.3333333333333333, 0.0]
Stacktrace:
 [1] macro expansion
   @ ~/.julia/packages/Graphs/mjncd/test/parallel/centrality/closeness.jl:14 [inlined]
 [2] macro expansion
   @ /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.6/Test/src/Test.jl:1151 [inlined]
 [3] top-level scope
   @ ~/.julia/packages/Graphs/mjncd/test/parallel/centrality/closeness.jl:2

And see it in CI too: https://github.com/JuliaGraphs/Graphs.jl/runs/3931288326

`period` function does not work correctly for abstract directed graphs

Currently the period functions seems to work only for SimpleDiGraph. It should either be restricted to that type or implemented in a way that works with other directed AbstractGraph.

How to reproduce:

julia> using Graphs, SimpleWeightedGraphs

julia> g = cycle_digraph(4)
{4, 4} directed simple Int64 graph

julia> gw = SimpleWeightedDiGraph(g)
{4, 4} directed simple Int64 graph with Float64 weights

julia> period(g)
4

julia> period(gw)
ERROR: MethodError: no method matching difference(::SimpleWeightedDiGraph{Int64, Float64}, ::SimpleDiGraph{Int64})
Closest candidates are:
  difference(::T, ::T) where T<:AbstractGraph at ~/.julia/dev/Graphs/src/operators.jl:196
Stacktrace:
 [1] period(::Type{IsDirected{SimpleWeightedDiGraph{Int64, Float64}}}, g::SimpleWeightedDiGraph{Int64, Float64})
   @ Graphs ~/.julia/dev/Graphs/src/connectivity.jl:503
 [2] period(g::SimpleWeightedDiGraph{Int64, Float64})
   @ Graphs ~/.julia/packages/SimpleTraits/l1ZsK/src/SimpleTraits.jl:331
 [3] top-level scope
   @ REPL[20]:1

Squash does not work correctly for AbstractGraph

The way the squash is currently implemented is by either calling SimpleGraph{T}(g) or SimpleDiGraph{T}(g) for some integer type T. This fails if g is a subtype of AbstractGraph for which these functions are not implemented. There are multiple ways to solve this:

  1. Restrict squash to SimpleGraph and SimpleDiGraph and leave the implementation of that function for other graph types open.
  2. Ensure that the constructors SimpleGraph{T}(g) or SimpleDiGraph{T}(g) work for for any kind of g::AbstractGraph.
  3. Require that subtypes of any kind of graph type SomeGraph <: AbstractGraph implement a constructor SomeGraph{T}(g) and adjust squash accordingly.

In my opinion, 1. is the way to go. 2. could lead to some information (such as metadata) being thrown away by squash which is probably not what the user wants. 3. would make the interface more complicated and would make existing packages not correspond to the interface anymore.

Refresh icon

Hi graphers! (graphistes?) Thank you for your efforts in migrating, maintaining, and updating this package, which so many of us find useful.

As a very minor contribution, here are some suggestions for a refreshed icon.

julia-graphs-logos

I noticed an oddity with the current icon. For some reason it's slightly transparent, which explains the subdued appearance when used with GitHub's Dark Mode.

Screenshot 2021-10-18 at 10 22 17

The current icon also uses the OG Julia duotone colour design, which was replaced by single colours sometime around v1.2.

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!

Consistent approach to graph direction

In traversals we use dir=[:in,:out] to tell functions to use in or out neighbors. We should probably have a more systematic approach based on a type like ReverseGraph{G} <: AbstractGraph. This came up in #36 where you have a symmetry in the algorithm that is invariant to the direction.

Standardized interface for graph modification

I understand why the Graphs.jl interface doesn't require the possibility of graph modification. However, wouldn't it be nice to specify at least the desired names add/rem_vertex/edge! in case people decide to implement them?

This could help standardize algorithms that include graph operations such as contractions (see #79)

Minors and contraction

It would be nice to have support for graph minors, at list for SimpleGraphs and possibly even in the interface by defining something like contract_edge!(g, s, d)

"Undirected" mode for shortest paths with directed graphs

This is a repost of this issue on the old repo.


Hi,
This is a follow up of this discussion.
Is there a way to efficiently find shortest paths in a directed graph while ignoring the direction of the edges ? (so without casting to a directed graph)
R seems to have an "undirected" mode for this.


Having thought more on this, better than a keyword in functions, it would be practical to have a new graph type that would be a wrapper around a directed graph, with redefinition of accessers to make it an undirected graph (a sort of graph view). This would avoid the heavy conversion to an undirected graph.

[BUG] Can't add vertices to a `MetaDiGraph`

Run this,

using LightGraphs, MetaGraphs, SimpleGraphs

g = MetaDiGraph()

add_vertex!(g.graph)
add_edge!(g,1,1)

and then make a new session swapping LightGraphs for Graphs.jl
you should get the following error:

ERROR: LoadError: MethodError: no method matching add_vertex!(::LightGraphs.SimpleGraphs.SimpleDiGraph{Int64})
Closest candidates are:
  add_vertex!(::SimpleDiGraph{T}) where T at /home/caseykneale/.julia/packages/Graphs/Mih78/src/SimpleGraphs/simpledigraph.jl:449
  add_vertex!(::Graphs.SimpleGraphs.SimpleGraph{T}) where T at /home/caseykneale/.julia/packages/Graphs/Mih78/src/SimpleGraphs/simplegraph.jl:526

Common interface for graphs with metadata

Hey!

There has been some talk recently about adding better support for graph metadata, so here's an issue to centralize our discussions. First of all, here are the packages that I'm aware of that deal with vertex- & edge-level attributes:

One idea would be to design a common interface extending AbstractGraph to work with metadata. I'm aware that the four packages above are very different, and that the case of edge weights probably deserves special treatment. On the other hand, agreeing on a common set of names for functions would bring clear benefits:

As food for thought, here are a few past discussions on this topic:

What is your take on this?

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.