Opened 12 years ago
Last modified 9 years ago
#9136 closed enhancement
more named graphs — at Version 20
Reported by: | mvngu | Owned by: | jason, ncohen, rlm |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | graph theory | Keywords: | |
Cc: | brunellus | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
The database of common graphs currently implements lots of named graphs. Below is a list of named graphs to add to that database. See also ticket #2686:
- Bidiakis cube --- #10307
- Brinkmann graph --- #10310
- Butterfly graph --- #10313
- Friendship graph --- #10315
- Dürer graph --- #10316
- Errera graph --- #10321
- Franklin graph --- #10322
- Goldner–Harary graph --- #10329
- Grötzsch graph --- #10330
- Herschel graph --- #10337
- Moser spindle --- #10338
- Balaban 10-cage
- Balaban 11-cage
- Double-star snark
- Ellingham–Horton graph
- fullerene graphs
- Harries–Wong graph
- Hoffman graph
- Holt graph
- Horton graph
- Kittell graph
- Markström graph
- McGee graph
- Meredith graph
- Sousselier graph
- Poussin graph
- Robertson graph
- Tutte's fragment
- Tutte graph
- Young–Fibonacci lattice
- Wagner graph
- Wiener-Araya graph
- Clebsch graph
- Hall–Janko graph
- Paley graph
- Shrikhande graph
- Möbius–Kantor graph
- Nauru graph
- Coxeter graph
- Tutte–Coxeter graph
- Dyck graph
- Foster graph
- Biggs–Smith graph
- Rado graph
- Folkman graph
- Gray graph
- Ljubljana graph
- Tutte 12-cage
- Blanuša snarks
- Szekeres snark
- Tietze's graph
- Watkins snark
Change History (20)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
- Description modified (diff)
- Milestone set to sage-wishlist
comment:3 Changed 12 years ago by
- Description modified (diff)
comment:4 Changed 12 years ago by
- Description modified (diff)
comment:5 Changed 12 years ago by
- Description modified (diff)
comment:6 Changed 12 years ago by
- Description modified (diff)
comment:7 follow-ups: ↓ 8 ↓ 17 Changed 12 years ago by
Many of these graphs can be trivially generated in GAP using its package Grape (a part of the optional gap_packages spkg) and a library of primitive groups (a part of optional databases_gap spkg). E.g. here is how to get Schlaefli graph:
sage: gap.load_package('grape') sage: gap.eval('G:=NullGraph(PrimitiveGroup(27,12),27);') 'rec( isGraph := true, order := 27, group := PSp(4, 3), \n schreierVector := [ -1, 1, 2, 1, 2, 2, 2, 2, 1, 2, 1, 2, 2, 2, 2, 1, 2, 1, \n 2, 1, 1, 2, 2, 1, 1, 1, 2 ], adjacencies := [ [ ] ], \n representatives := [ 1 ], isSimple := true )' sage: gap.eval('AddEdgeOrbit(G,[1,2]);') '' sage: gap.eval('VertexDegrees(G);') '[ 10 ]' sage: edges=gap('Orbit(G.group,[1,2],OnSets)') sage: len(edges) 135 sage: schlaefli=Graph([[int(x[1])-1,int(x[2])-1] for x in edges]) sage: schlaefli.degree() [10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10] sage: schlaefli.diameter() 2
IMHO there is a more fundamental issue here: Sage should handle such graphs in an efficient way --- just keeping all the edges is pretty much a waste, in particular for bigger examples with hundreds of vertices...
comment:8 in reply to: ↑ 7 Changed 12 years ago by
Replying to dimpase:
Many of these graphs can be trivially generated in GAP using its package Grape (a part of the optional gap_packages spkg) and a library of primitive groups (a part of optional databases_gap spkg).
actually, Grape isn't even needed (I mentioned it for illustrative purposes): to construct the Sage graph, all you need is the following:
sage: edges=gap('Orbit(PrimitiveGroup(27,12),[1,2],OnSets)') sage: schlaefli=Graph([[int(x[1])-1,int(x[2])-1] for x in edges])
PS. To get e.g. Hall-Janko graph, use PrimitiveGroup(100,1)
...
comment:9 Changed 12 years ago by
- Description modified (diff)
comment:10 Changed 12 years ago by
- Description modified (diff)
comment:11 Changed 12 years ago by
- Description modified (diff)
comment:12 Changed 12 years ago by
- Description modified (diff)
comment:13 Changed 12 years ago by
- Description modified (diff)
comment:14 Changed 12 years ago by
Fullerens are in fact a family, that can be generated. G.Brinkmann wrote a program called fullgen http://cs.anu.edu.au/~bdm/plantri/ that does just this, generating all non-isomorphic fullerens with given number of hexagonal faces. Unfortunately it has a weird license, so it cannot be just hooked up to Sage, at least not in a standard package.
comment:15 follow-up: ↓ 16 Changed 12 years ago by
I have been sighing at plantri for a while.... I *need* to generate random planar graphs :-p
Nathann
comment:16 in reply to: ↑ 15 Changed 12 years ago by
Replying to ncohen:
I have been sighing at plantri for a while.... I *need* to generate random planar graphs
:-p
Sage way: throw random points on the sphere, generate the facets of their convex closuse (using e.g. cdd), then take the skeleton of the polytope (again, using cdd). Slow, but trivial to code :-)
comment:17 in reply to: ↑ 7 ; follow-up: ↓ 18 Changed 12 years ago by
Replying to dimpase:
IMHO there is a more fundamental issue here: Sage should handle such graphs in an efficient way --- just keeping all the edges is pretty much a waste, in particular for bigger examples with hundreds of vertices...
The underlying architecture is already in place; one needs only to implement a GraphBackend? which represents the graph in question. Implementing simple methods such as has_edge, has_vertex, etc. one can then get the rest of the methods automatically. Check out the source!
comment:18 in reply to: ↑ 17 ; follow-up: ↓ 19 Changed 12 years ago by
Replying to rlm:
Replying to dimpase:
IMHO there is a more fundamental issue here: Sage should handle such graphs in an efficient way --- just keeping all the edges is pretty much a waste, in particular for bigger examples with hundreds of vertices...
The underlying architecture is already in place; one needs only to implement a GraphBackend? which represents the graph in question. Implementing simple methods such as has_edge, has_vertex, etc. one can then get the rest of the methods automatically. Check out the source!
I am not sure I understand how to implement things like add_vertex() and add_edge() - as we would start with a permutation group G, the set of vertices is the domain of the group, and edges cannot be added one by one, but only as whole G-orbits. (Alternatively, not all orbits of G are used as the vertex set, and then adding a vertex would mean adding its G-orbit.)
comment:19 in reply to: ↑ 18 Changed 12 years ago by
Replying to dimpase:
I am not sure I understand how to implement things like add_vertex() and add_edge() - as we would start with a permutation group G, the set of vertices is the domain of the group, and edges cannot be added one by one, but only as whole G-orbits. (Alternatively, not all orbits of G are used as the vertex set, and then adding a vertex would mean adding its G-orbit.)
Well, you can always raise an error in the add_vertex function:
RuntimeError?: You can't add vertices to this kind of graph.
Or something similar. Then whenever you called a function which tried to add a vertex you would get that error, but the rest of the graph library would work just fine.
comment:20 Changed 12 years ago by
- Description modified (diff)
My god O_O SO you are basically saying I'm not sending enough ? :-D
To be honest I have tried to implement some of them, but felt I should ask for the help of Sage's algebraists... This one, for example : is there any way to build it using Sage's tools ?
http://www.win.tue.nl/~aeb/graphs/Schlaefli.html
Nathann