DOCSLIB.ORG

GOLD 3 Un Lenguaje De Programación Imperativo Para La Manipulación De Grafos Y Otras Estructuras De Datos

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
GOLD 3 Un Lenguaje De Programación Imperativo Para La Manipulación De Grafos Y Otras Estructuras De Datos GOLD 3 Un lenguaje de programación imperativo para la manipulación de grafos y otras estructuras de datos Autor Alejandro Sotelo Arévalo UNIVERSIDAD DE LOS ANDES Asesora Silvia Takahashi Rodríguez, Ph.D. UNIVERSIDAD DE LOS ANDES TESIS DE MAESTRÍA EN INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN FACULTAD DE INGENIERÍA UNIVERSIDAD DE LOS ANDES BOGOTÁ D.C., COLOMBIA ENERO 27 DE 2012 > > > A las personas que más quiero en este mundo: mi madre Gladys y mi novia Alexandra. > > > Abstract Para disminuir el esfuerzo en la programación de algoritmos sobre grafos y otras estructuras de datos avanzadas es necesario contar con un lenguaje de propósito específico que se preocupe por mejorar la legibilidad de los programas y por acelerar el proceso de desarrollo. Este lenguaje debe mezclar las virtudes del pseudocódigo con las de un lenguaje de alto nivel como Java o C++ para que pueda ser fácilmente entendido por un matemático, por un científico o por un ingeniero. Además, el lenguaje debe ser fácilmente interpretado por las máquinas y debe poder competir con la expresividad de los lenguajes de propósito general. GOLD (Graph Oriented Language Domain) satisface este objetivo, siendo un lenguaje de propósito específico imperativo lo bastante cercano al lenguaje utilizado en el texto Introduction to Algorithms de Thomas Cormen et al. [1] como para ser considerado una especie de pseudocódigo y lo bastante cercano al lenguaje Java como para poder utilizar la potencia de su librería estándar y del entorno de programación Eclipse. Índice general I Preliminares 1 1 Introducción 2 1.1 Resumen ............................................... 2 1.2 Contexto................................................ 2 1.3 Motivación .............................................. 3 1.4 Justificación.............................................. 5 1.5 Descripción del problema....................................... 6 1.6 Objetivos ............................................... 8 1.7 ¿Cómo leer este documento?..................................... 9 2 Antecedentes 11 2.1 CSet .................................................. 11 2.2 GOLD 1 ................................................ 13 2.3 GOLD 2 (GOLD+).......................................... 15 3 Estado del arte 20 3.1 Lenguajes para describir grafos.................................... 20 3.1.1 GOLD 1 ............................................ 21 3.1.2 GML ............................................. 22 3.1.3 Graphviz DOT ........................................ 22 3.1.4 Dialectos XML: GraphML, GXL, DGML y XGMML .................... 23 3.2 Aplicaciones de escritorio para manipular grafos .......................... 24 3.2.1 GIDEN ............................................ 24 3.2.2 Grafos ............................................ 25 3.3 Frameworks y librerías sobre grafos ................................. 26 3.3.1 GTL .............................................. 26 3.3.2 Gravisto ........................................... 28 3.3.3 FGL .............................................. 29 3.3.4 JUNG ............................................. 29 3.3.5 JGraphT ........................................... 30 3.3.6 Implementaciones de referencia de Cormen et al....................... 31 3.4 Lenguajes para implementar algoritmos sobre grafos ........................ 32 3.4.1 GOLD 2 (GOLD+)...................................... 32 3.4.2 GP .............................................. 33 3.4.3 Gremlin ............................................ 34 3.4.4 GRAAL ............................................ 35 4 Marco teórico 36 II ÍNDICE GENERAL III 4.1 Lenguajes de propósito general.................................... 36 4.1.1 Introducción ......................................... 37 4.1.1.1 Paradigmas de programación........................... 38 4.1.1.2 Criterios para evaluar un lenguaje de programación ............... 39 4.1.2 Sintaxis............................................ 41 4.1.2.1 Criterios sintácticos generales........................... 42 4.1.2.2 Elementos sintácticos de un lenguaje....................... 43 4.1.3 Semántica........................................... 44 4.1.3.1 Semántica axiomática............................... 44 4.1.3.2 Semántica denotacional.............................. 44 4.1.3.3 Semántica operacional............................... 44 4.1.4 Compilación ......................................... 45 4.1.4.1 Análisis del código fuente............................. 45 4.1.4.2 Síntesis del código ejecutable........................... 45 4.1.5 Conceptos básicos ...................................... 46 4.1.5.1 Valores y tipos................................... 46 4.1.5.2 Expresiones y evaluación............................. 48 4.1.5.3 Variables y almacenamiento............................ 50 4.1.5.4 Comandos y control de flujo ........................... 51 4.1.5.5 Ataduras (bindings) y alcance (scope) ...................... 53 4.1.5.6 Procedimientos y funciones............................ 54 4.1.5.7 Módulos y paquetes................................ 54 4.2 Lenguajes de propósito específico .................................. 55 4.2.1 Definición .......................................... 55 4.2.2 Categorías .......................................... 56 4.2.3 Tópicos generales (Fowler).................................. 56 4.2.4 Patrones de diseño (Spinellis) ................................ 57 II Propuesta de solución 58 5 Requerimientos 59 5.1 Criterios de calidad de acuerdo con el estándar ISO/IEC 9126.................... 60 5.1.1 Funcionalidad (Functionality)................................ 60 5.1.2 Confiabilidad (Reliability).................................. 66 5.1.3 Usabilidad (Usability) .................................... 66 5.1.4 Eficiencia (Efficiency) .................................... 66 5.1.5 Mantenibilidad (Maintainability) .............................. 67 5.1.6 Portabilidad (Portability)................................... 67 5.2 Criterios de calidad de acuerdo con Pratt y Zelkowitz........................ 67 5.3 Criterios de calidad de acuerdo con Watt............................... 69 6 Herramientas 71 6.1 Tecnologías.............................................. 71 6.1.1 Java .............................................. 71 6.1.2 Eclipse ............................................ 72 6.1.3 Xtext ............................................. 73 6.2 Librerías externas........................................... 73 IV ÍNDICE GENERAL 6.2.1 JUNG ............................................. 73 6.2.2 JGraphT ........................................... 75 6.2.3 Implementaciones de referencia de Cormen et al....................... 76 6.2.4 Apfloat ............................................ 76 7 Diseño 77 7.1 Pragmática .............................................. 77 7.1.1 Clasificación......................................... 77 7.1.2 Procesamiento ........................................ 78 7.2 Sintaxis................................................ 80 7.2.1 Elementos léxicos ...................................... 81 7.2.2 Tipos............................................. 83 7.2.3 Expresiones.......................................... 85 7.2.4 Variables........................................... 91 7.2.5 Comandos .......................................... 92 7.2.6 Procedimientos........................................ 100 7.2.7 Programas .......................................... 105 7.2.8 Alcance (scope)........................................ 107 7.3 Semántica............................................... 111 7.3.1 Semántica Denotacional ................................... 111 7.3.2 Semántica Axiomática.................................... 114 7.3.3 Semántica Operacional.................................... 114 8 Implementación 115 8.1 Entorno de desarrollo integrado (IDE)................................ 115 8.1.1 Tipografía (font) ....................................... 116 8.1.2 Mapa de caracteres (character map)............................. 119 8.1.3 Editor de código fuente (source code editor) ........................ 123 8.1.4 Proveedor de codificación de caracteres (encoding provider) . 123 8.1.5 Resaltado de la sintaxis (syntax highlighting)........................ 124 8.1.6 Formateado de código (code formatting)........................... 127 8.1.7 Autoedición de código (autoedit strategies)......................... 128 8.1.8 Plegamiento de código (code folding)............................ 129 8.1.9 Emparejamiento de paréntesis (bracket matching)...................... 129 8.1.10 Ayudas de contenido (content assist) ............................ 130 8.1.11 Validación de código (code validation) ........................... 131 8.1.12 Convertidores de valores (value converters)......................... 132 8.1.13 Proveedor de etiquetas (label provider) ........................... 134 8.1.14 Esquema semántico (outline view).............................. 135 8.1.15 Contribuciones de menú (menu contributions)........................ 135 8.1.16 Generador de código (code generator)............................ 137 8.1.17 Proveedor de alcance (scope provider)............................ 139 8.1.18 Asistentes (wizards) ..................................... 140 8.2 Núcleo del lenguaje.......................................... 142 8.2.1 Gramática (grammar) .................................... 142 8.2.2 Analizador léxico (lexer)................................... 144 8.2.3 Analizador sintáctico (parser)................................ 145 8.2.4
Load more

Recommended publications
  • Practical Parallel Hypergraph Algorithms
    Practical Parallel Hypergraph Algorithms Julian Shun [email protected] MIT CSAIL Abstract v While there has been signicant work on parallel graph pro- 0 cessing, there has been very surprisingly little work on high- e0 performance hypergraph processing. This paper presents v0 v1 v1 a collection of ecient parallel algorithms for hypergraph processing, including algorithms for betweenness central- e1 ity, maximal independent set, k-core decomposition, hyper- v2 trees, hyperpaths, connected components, PageRank, and v2 v3 e single-source shortest paths. For these problems, we either 2 provide new parallel algorithms or more ecient implemen- v3 tations than prior work. Furthermore, our algorithms are theoretically-ecient in terms of work and depth. To imple- (a) Hypergraph (b) Bipartite representation ment our algorithms, we extend the Ligra graph processing Figure 1. An example hypergraph representing the groups framework to support hypergraphs, and our implementa- , , , , , , and , , and its bipartite repre- { 0 1 2} { 1 2 3} { 0 3} tions benet from graph optimizations including switching sentation. between sparse and dense traversals based on the frontier size, edge-aware parallelization, using buckets to prioritize processing of vertices, and compression. Our experiments represented as hyperedges, can contain an arbitrary number on a 72-core machine and show that our algorithms obtain of vertices. Hyperedges correspond to group relationships excellent parallel speedups, and are signicantly faster than among vertices (e.g., a community in a social network). An algorithms in existing hypergraph processing frameworks. example of a hypergraph is shown in Figure 1a. CCS Concepts • Computing methodologies → Paral- Hypergraphs have been shown to enable richer analy- lel algorithms; Shared memory algorithms.
    [Show full text]
  • Fcastone - FCA file Format Conversion and Interoperability Software
    FcaStone - FCA file format conversion and interoperability software Uta Priss Napier University, School of Computing, [email protected] www.upriss.org.uk Abstract. This paper presents FcaStone - a software for FCA file format con- version and interoperability. The paper both describes the features of FcaStone and discusses FCA interoperability issues (such as the specific difficulties en- countered when connecting FCA tools to other tools). The paper ends with a call to the FCA community to develop some sort of standard FCA Interchange For- mat, which could be used for data exchange between stand-alone applications and across the web. 1 Introduction FcaStone1 (named in analogy to ”Rosetta Stone”) is a command-line utility that con- verts between the file formats of commonly-used FCA2 tools (such as ToscanaJ, Con- Exp, Galicia, Colibri3) and between FCA formats and other graph and vector graph- ics formats. The main purpose of FcaStone is to improve the interoperability between FCA, graph editing and vector graphics software. Because it is a command-line tool, FcaStone can easily be incorporated into server-side web applications, which generate concept lattices on demand. FcaStone is open source software and available for down- load from Sourceforge. FcaStone is written in an interpreted language (Perl) and thus platform-independent. Installation on Linux and Apple OS X consists of copying the file to a suitable location. Installation on Windows has also been tested and is also fairly easy. The need for interoperability software was highlighted in discussions among ICCS participants in recent years. Several ICCS authors expressed disappointment with the lack of progress in conceptual structures (CS) research with respect to applications and software (Chein & Genest (2000); Keeler & Pfeiffer (2006)) and with respect to current web developments (Rudolph et al., 2007).
    [Show full text]
  • Multilevel Hypergraph Partitioning with Vertex Weights Revisited
    Multilevel Hypergraph Partitioning with Vertex Weights Revisited Tobias Heuer ! Karlsruhe Institute of Technology, Karlsruhe, Germany Nikolai Maas ! Karlsruhe Institute of Technology, Karlsruhe, Germany Sebastian Schlag ! Karlsruhe Institute of Technology, Karlsruhe, Germany Abstract The balanced hypergraph partitioning problem (HGP) is to partition the vertex set of a hypergraph into k disjoint blocks of bounded weight, while minimizing an objective function defined on the hyperedges. Whereas real-world applications often use vertex and edge weights to accurately model the underlying problem, the HGP research community commonly works with unweighted instances. In this paper, we argue that, in the presence of vertex weights, current balance constraint definitions either yield infeasible partitioning problems or allow unnecessarily large imbalances and propose a new definition that overcomes these problems. We show that state-of-the-art hypergraph partitioners often struggle considerably with weighted instances and tight balance constraints (even with our new balance definition). Thus, we present a recursive-bipartitioning technique that isable to reliably compute balanced (and hence feasible) solutions. The proposed method balances the partition by pre-assigning a small subset of the heaviest vertices to the two blocks of each bipartition (using an algorithm originally developed for the job scheduling problem) and optimizes the actual partitioning objective on the remaining vertices. We integrate our algorithm into the multilevel hypergraph
    [Show full text]
  • On Decomposing a Hypergraph Into K Connected Sub-Hypergraphs
    Egervary´ Research Group on Combinatorial Optimization Technical reportS TR-2001-02. Published by the Egrerv´aryResearch Group, P´azm´any P. s´et´any 1/C, H{1117, Budapest, Hungary. Web site: www.cs.elte.hu/egres . ISSN 1587{4451. On decomposing a hypergraph into k connected sub-hypergraphs Andr´asFrank, Tam´asKir´aly,and Matthias Kriesell February 2001 Revised July 2001 EGRES Technical Report No. 2001-02 1 On decomposing a hypergraph into k connected sub-hypergraphs Andr´asFrank?, Tam´asKir´aly??, and Matthias Kriesell??? Abstract By applying the matroid partition theorem of J. Edmonds [1] to a hyper- graphic generalization of graphic matroids, due to M. Lorea [3], we obtain a gen- eralization of Tutte's disjoint trees theorem for hypergraphs. As a corollary, we prove for positive integers k and q that every (kq)-edge-connected hypergraph of rank q can be decomposed into k connected sub-hypergraphs, a well-known result for q = 2. Another by-product is a connectivity-type sufficient condition for the existence of k edge-disjoint Steiner trees in a bipartite graph. Keywords: Hypergraph; Matroid; Steiner tree 1 Introduction An undirected graph G = (V; E) is called connected if there is an edge connecting X and V X for every nonempty, proper subset X of V . Connectivity of a graph is equivalent− to the existence of a spanning tree. As a connected graph on t nodes contains at least t 1 edges, one has the following alternative characterization of connectivity. − Proposition 1.1. A graph G = (V; E) is connected if and only if the number of edges connecting distinct classes of is at least t 1 for every partition := V1;V2;:::;Vt of V into non-empty subsets.P − P f g ?Department of Operations Research, E¨otv¨osUniversity, Kecskem´etiu.
    [Show full text]
  • Hypergraph Packing and Sparse Bipartite Ramsey Numbers
    Hypergraph packing and sparse bipartite Ramsey numbers David Conlon ∗ Abstract We prove that there exists a constant c such that, for any integer ∆, the Ramsey number of a bipartite graph on n vertices with maximum degree ∆ is less than 2c∆n. A probabilistic argument due to Graham, R¨odland Ruci´nskiimplies that this result is essentially sharp, up to the constant c in the exponent. Our proof hinges upon a quantitative form of a hypergraph packing result of R¨odl,Ruci´nskiand Taraz. 1 Introduction For a graph G, the Ramsey number r(G) is defined to be the smallest natural number n such that, in any two-colouring of the edges of Kn, there exists a monochromatic copy of G. That these numbers exist was proven by Ramsey [19] and rediscovered independently by Erd}osand Szekeres [10]. Whereas the original focus was on finding the Ramsey numbers of complete graphs, in which case it is known that t t p2 r(Kt) 4 ; ≤ ≤ the field has broadened considerably over the years. One of the most famous results in the area to date is the theorem, due to Chvat´al,R¨odl,Szemer´ediand Trotter [7], that if a graph G, on n vertices, has maximum degree ∆, then r(G) c(∆)n; ≤ where c(∆) is just some appropriate constant depending only on ∆. Their proof makes use of the regularity lemma and because of this the bound it gives on the constant c(∆) is (and is necessarily [11]) very bad. The situation was improved somewhat by Eaton [8], who proved, by using a variant of the regularity lemma, that the function c(∆) may be taken to be of the form 22c∆ .
    [Show full text]
  • Hypernetwork Science: from Multidimensional Networks to Computational Topology∗
    Hypernetwork Science: From Multidimensional Networks to Computational Topology∗ Cliff A. Joslyn,y Sinan Aksoy,z Tiffany J. Callahan,x Lawrence E. Hunter,x Brett Jefferson,z Brenda Praggastis,y Emilie A.H. Purvine,y Ignacio J. Tripodix March, 2020 Abstract cations, and physical infrastructure often afford a rep- resentation as such a set of entities with binary rela- As data structures and mathematical objects used tionships, and hence may be analyzed utilizing graph for complex systems modeling, hypergraphs sit nicely theoretical methods. poised between on the one hand the world of net- Graph models benefit from simplicity and a degree of work models, and on the other that of higher-order universality. But as abstract mathematical objects, mathematical abstractions from algebra, lattice the- graphs are limited to representing pairwise relation- ory, and topology. They are able to represent com- ships between entities, while real-world phenomena plex systems interactions more faithfully than graphs in these systems can be rich in multi-way relation- and networks, while also being some of the simplest ships involving interactions among more than two classes of systems representing topological structures entities, dependencies between more than two vari- as collections of multidimensional objects connected ables, or properties of collections of more than two in a particular pattern. In this paper we discuss objects. Representing group interactions is not possi- the role of (undirected) hypergraphs in the science ble in graphs natively, but rather requires either more of complex networks, and provide a mathematical complex mathematical objects, or coding schemes like overview of the core concepts needed for hypernet- “reification” or semantic labeling in bipartite graphs.
    [Show full text]
  • The Hitchhiker's Guide to Graph Exchange Formats
    The Hitchhiker’s Guide to Graph Exchange Formats Prof. Matthew Roughan [email protected] http://www.maths.adelaide.edu.au/matthew.roughan/ Work with Jono Tuke UoA June 4, 2015 M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 1 / 31 Graphs Graph: G(N; E) I N = set of nodes (vertices) I E = set of edges (links) Often we have additional information, e.g., I link distance I node type I graph name M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 2 / 31 Why? To represent data where “connections” are 1st class objects in their own right I storing the data in the right format improves access, processing, ... I it’s natural, elegant, efficient, ... Many, many datasets M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 3 / 31 ISPs: Internode: layer 3 http: //www.internode.on.net/pdf/network/internode-domestic-ip-network.pdf M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 4 / 31 ISPs: Level 3 (NA) http://www.fiberco.org/images/Level3-Metro-Fiber-Map4.jpg M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 5 / 31 Telegraph submarine cables http://en.wikipedia.org/wiki/File:1901_Eastern_Telegraph_cables.png M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 6 / 31 Electricity grid M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 7 / 31 Bus network (Adelaide CBD) M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 8 / 31 French Rail http://www.alleuroperail.com/europe-map-railways.htm M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 9 / 31 Protocol relationships M.Roughan (UoA) Hitch Hikers Guide June 4, 2015 10 / 31 Food web M.Roughan (UoA) Hitch Hikers
    [Show full text]
  • A DSL for Defining Instance Templates for the ASMIG System
    A DSL for defining instance templates for the ASMIG system Andrii Kovalov Dissertation 2014 Erasmus Mundus MSc in Dependable Software Systems Department of Computer Science National University of Ireland, Maynooth Co. Kildare, Ireland A dissertation submitted in partial fulfilment of the requirements for the Erasmus Mundus MSc Dependable Software Systems Head of Department : Dr Adam Winstanley Supervisor : Dr James Power Date: June 2014 Abstract The area of our work is test data generation via automatic instantiation of software models. Model instantiation or model finding is a process of find- ing instances of software models. For example, if a model is represented as a UML class diagram, the instances of this model are UML object diagrams. Model instantiation has several applications: finding solutions to problems expressed as models, model testing and test data generation. There are sys- tems that automatically generate model instances, one of them is ASMIG (A Small Metamodel Instance Generator). This system is focused on a `problem solving' use case. The motivation of our work is to adapt ASMIG system for use as a test data generator and make the instance generation process more transparent for the user. In order to achieve this we provided a way for the user to interact with ASMIG internal data structure, the instance template graph via a specially designed graph definition domain-specific language. As a result, the user is able to configure the instance template in order to get plausible instances, which can be then used as test data. Although model finding is only suitable for obtaining test inputs, but not the expected test outputs, it can be applied effectively for smoke testing of systems that process complex hierarchic data structures such as programming language parsers.
    [Show full text]
  • 2 Graphs and Graph Theory
    2 Graphs and Graph Theory chapter:graphs Graphs are the mathematical objects used to represent networks, and graph theory is the branch of mathematics that involves the study of graphs. Graph theory has a long history. The notion of graph was introduced for the first time in 1763 by Euler, to settle a famous unsolved problem of his days, the so-called “K¨onigsberg bridges” problem. It is no coin- cidence that the first paper on graph theory arose from the need to solve a problem from the real world. Also subsequent works in graph theory by Kirchhoff and Cayley had their root in the physical world. For instance, Kirchhoff’s investigations on electric circuits led to his development of a set of basic concepts and theorems concerning trees in graphs. Nowadays, graph theory is a well established discipline which is commonly used in areas as diverse as computer science, sociology, and biology. To make some examples, graph theory helps us to schedule airplane routings, and has solved problems such as finding the maximum flow per unit time from a source to a sink in a network of pipes, or coloring the regions of a map using the minimum number of different colors so that no neighbouring regions are colored the same way. In this chapter we introduce the basic definitions, set- ting up the language we will need in the following of the book. The two last sections are respectively devoted to the proof of the Euler theorem, and to the description of a graph as an array of numbers.
    [Show full text]
  • Data Structures and Network Algorithms [Tarjan 1987-01-01].Pdf
    CBMS-NSF REGIONAL CONFERENCE SERIES IN APPLIED MATHEMATICS A series of lectures on topics of current research interest in applied mathematics under the direction of the Conference Board of the Mathematical Sciences, supported by the National Science Foundation and published by SIAM. GAKRHT BiRKiion , The Numerical Solution of Elliptic Equations D. V. LINDIY, Bayesian Statistics, A Review R S. VAR<;A. Functional Analysis and Approximation Theory in Numerical Analysis R R H:\II\DI:R, Some Limit Theorems in Statistics PXIKK K Bin I.VISLI -y. Weak Convergence of Measures: Applications in Probability .1. I.. LIONS. Some Aspects of the Optimal Control of Distributed Parameter Systems R(H;I:R PI-NROSI-:. Tecltniques of Differentia/ Topology in Relativity Hi.KM \N C'ui KNOI r. Sequential Analysis and Optimal Design .1. DI'KHIN. Distribution Theory for Tests Based on the Sample Distribution Function Soi I. Ri BINO\\, Mathematical Problems in the Biological Sciences P. D. L\x. Hyperbolic Systems of Conservation Laws and the Mathematical Theory of Shock Waves I. .1. Soioi.NUiiRci. Cardinal Spline Interpolation \\.\\ SiMii.R. The Theory of Best Approximation and Functional Analysis WI-.KNI R C. RHHINBOLDT, Methods of Solving Systems of Nonlinear Equations HANS I-'. WHINBKRQKR, Variational Methods for Eigenvalue Approximation R. TYRRM.I. ROCKAI-KLI.AK, Conjugate Dtialitv and Optimization SIR JAMKS LIGHTHILL, Mathematical Biofhtiddynamics GI-.RAKD SAI.ION, Theory of Indexing C \ rnLi-:i;.N S. MORAWKTX, Notes on Time Decay and Scattering for Some Hyperbolic Problems F. Hoi'i'hNSTKAm, Mathematical Theories of Populations: Demographics, Genetics and Epidemics RK HARD ASKF;Y.
    [Show full text]
  • Graphs Introduction and Depth-First Algorithm Carol Zander
    Graphs Introduction and Depth‐first algorithm Carol Zander Introduction to graphs Graphs are extremely common in computer science applications because graphs are common in the physical world. Everywhere you look, you see a graph. Intuitively, a graph is a set of locations and edges connecting them. A simple example would be cities on a map that are connected by roads. Or cities connected by airplane routes. Another example would be computers in a local network that are connected to each other directly. Constellations of stars (among many other applications) can be also represented this way. Relationships can be represented as graphs. Section 9.1 has many good graph examples. Graphs can be viewed in three ways (trees, too, since they are special kind of graph): 1. A mathematical construction – this is how we will define them 2. An abstract data type – this is how we will think about interfacing with them 3. A data structure – this is how we will implement them The mathematical construction gives the definition of a graph: graph G = (V, E) consists of a set of vertices V (often called nodes) and a set of edges E (sometimes called arcs) that connect the edges. Each edge is a pair (u, v), such that u,v ∈V . Every tree is a graph, but not vice versa. There are two types of graphs, directed and undirected. In a directed graph, the edges are ordered pairs, for example (u,v), indicating that a path exists from u to v (but not vice versa, unless there is another edge.) For the edge, (u,v), v is said to be adjacent to u, but not the other way, i.e., u is not adjacent to v.
    [Show full text]
  • Package 'Igraph'
    Package ‘igraph’ February 28, 2013 Version 0.6.5-1 Date 2013-02-27 Title Network analysis and visualization Author See AUTHORS file. Maintainer Gabor Csardi <[email protected]> Description Routines for simple graphs and network analysis. igraph can handle large graphs very well and provides functions for generating random and regular graphs, graph visualization,centrality indices and much more. Depends stats Imports Matrix Suggests igraphdata, stats4, rgl, tcltk, graph, Matrix, ape, XML,jpeg, png License GPL (>= 2) URL http://igraph.sourceforge.net SystemRequirements gmp, libxml2 NeedsCompilation yes Repository CRAN Date/Publication 2013-02-28 07:57:40 R topics documented: igraph-package . .5 aging.prefatt.game . .8 alpha.centrality . 10 arpack . 11 articulation.points . 15 as.directed . 16 1 2 R topics documented: as.igraph . 18 assortativity . 19 attributes . 21 autocurve.edges . 23 barabasi.game . 24 betweenness . 26 biconnected.components . 28 bipartite.mapping . 29 bipartite.projection . 31 bonpow . 32 canonical.permutation . 34 centralization . 36 cliques . 39 closeness . 40 clusters . 42 cocitation . 43 cohesive.blocks . 44 Combining attributes . 48 communities . 51 community.to.membership . 55 compare.communities . 56 components . 57 constraint . 58 contract.vertices . 59 conversion . 60 conversion between igraph and graphNEL graphs . 62 convex.hull . 63 decompose.graph . 64 degree . 65 degree.sequence.game . 66 dendPlot . 67 dendPlot.communities . 68 dendPlot.igraphHRG . 70 diameter . 72 dominator.tree . 73 Drawing graphs . 74 dyad.census . 80 eccentricity . 81 edge.betweenness.community . 82 edge.connectivity . 84 erdos.renyi.game . 86 evcent . 87 fastgreedy.community . 89 forest.fire.game . 90 get.adjlist . 92 get.edge.ids . 93 get.incidence . 94 get.stochastic .
    [Show full text]