i have a data structure for my compiler (such as ast) , and i need a method to print it (like ms visio) and verify its contents (i need to verify the contents of the ast nodes)
note : i dont want to print it to the console , i am using c++ & qt
thanks
It sounds like you could use graphviz - www.graphviz.org. It's a software package that takes a graph (such as your AST, or probably any other interesting compiler data structure) and produces coordinates for each graph node so that you can draw the graph at that coordinate and it will look reasonably good.
You can use this to implement your own drawing routines (In Qt Canvas, I assume) or use graphviz's own programs.
Related
I want to implement graph data structure and want to make its graphical view in any language like Windows form or java any one. If you know about it then please tell me.
Tall order.
When I was learning data-structures I always found this page to be helpful for understanding data structures.
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
This has a bunch of different types of graphs if you scroll down.
The javascript version of each visualization is still maintained. Maybe you can use this as a point of departure and try to reverse engineer whatever specific graph algorithm you are trying to construct.
So I'm trying to implement a project where I have graph data (few 100 nodes for now, but could become a million later) stored as a json file.
I'm using NetworkX libraries in python to generate all the data
from some information, and then sending over the json file to the
client side.
I'm using d3.js to represent the graph in javascript
on the client side.
Now, on the user's request, I need to delete the shortest path between two nodes of the user's choice in my graph and show them the resulting graph.
I know that this processing has to be done on the client-side to prevent excess server load, but this is what I'm unsure about:
An optimized graph library is what does this the fastest. In fact, NetworkX probably has a ready-made function for this. But it's in python. Is writing a shortest path deletion function in javascript the intelligent thing to do?
Does d3.js have these sort of functions? Or is it a library only for representing stuff graphically?
Thanks.
D3 doesn't have functions for this. It sounds like in your case the best way to go would be to implement this functionality in Javascript yourself (or find a library that does it). If you need more sophisticated functionality however, relying on something like NetworkX is almost certainly going to be easier and faster to implement though.
I am interested in persisting individual directed graphs. This question is not asking for a full-scale graph database solution, but for a document format that I can use to save and individual arbitrary directed graph. I don't know what notation and file format would be the smartest choice.
My primary concerns are:
Expressiveness/Flexibility - I want the ability to express graphs of different types. While the standard use case would be a simple directed graph, it should be possible to express trees, cyclical graphs, multi-graphs. As a bare minimum, I would expect support for labeling and weighting of edges and nodes. Notations for describing higraphs and edge composition/hyper-edges would also be highly desirable, although I am aware that such solutions may not exist.
Type System-Independence - I am interested in representing the structural qualities of graphs. Some solutions include an extensible type system for typed edges and nodes (e.g. RDF/OWL). I would only be interested in such a representation, if there were a clearly defined canonical decomposition of typed elements into primitives (nodes/edges/attributes). What I am trying to avoid here is the ability for multiple representations of equivalent graphs, where the equivalence is not discernible.
Canonical Representation - There should be a mechanism that allows the graph to be represented canonically (in such a way that lexical equivalence of canonical-representations could be used to determine equivalence).
Presentation Independent - I would prefer a notation that is not dependent upon the presentation of the graph. This would include spatial orientation, colors, font, etc. I am only interested in representing the data. One of the features I don't like about DOT language, DGML or SVG (at least for this particular purpose) is the focus on visual representation.
Standardized / Open / Compatible - The less implementation work that I have to do, the better. If the format is standardized and reliable tools already exist for working with the format, then it is more preferable. Accompanying this requirement is another, that the format should be highly-compatible. The proprietary nature of Microsoft's DGML is a reason for my aversion, despite the Visual Studio tooling and the fact that I work primarily with .NET (now). The fact that W3C publishes RDF standards is a motivation for considering a limited subset of RDF as a representational tool. I also appreciate GXL and GraphML, because they have well documented xml schemas, thereby facilitating the ability to integrate their data with any xml-compatible software package.
Simplicity / Readability - I appreciate human-readable syntax and ease of interpretation. I also appreciate representation that simplifies parsing. For this reason, I like GML, but I am concerned it is not mainstream enough to be a realistic choice. I would also consider JSON or YAML for readability, if they were not so limited in their respective abilities to represent complex (non-DAG) structures.
Efficiency / Concise Representation - It's worth considering that whatever format I end up choosing will inevitably have to be persisted and transferred over some network. Therefore, file size is a relevant consideration.
Overview
I recognize that I will most likely be unable to find a solution that satisfies every criteria on my wishlist. I am simply asking for the file format that is closest to what I want and that doesn't limit extensibility for unsupported use cases.
ObWindyPreamble: in the RDF world, there are a gazillion different surface syntax formats to choose from. RDF itself is an abstract metamodel for data, not directly a "graph syntax". You can of course directly represent a graph in RDF (since RDF models are graphs), but given that you want to represent different kinds of graphs you may end up with having to abstract away, and actually create an RDF vocabulary for representing different types of graphs.
All in all, I'm not convinced that RDF is the best way to go for you, but if you'd choose one, I'd say that RDF's Turtle syntax is something worth looking into. It certainly ticks the readability and simplicity boxes, as well as being a standard (well, almost... W3C is working on standardizing it) and having wide (open-source) tool support.
RDF models roughly follow set semantics, which means that a canonical syntax representation can not really be enforced: two files can have information in a different order without it affecting the actual model, or even can contain duplicate information. However, if you enforce a simple sorting algorithm when producing files (something for which most RDF parsers/writers have support), you should be able to get away with doing line-based comparisons and determining graph equivalence based on surface syntax.
Just as a simple example, let's assume we have a very simple, directed, labeled graph:
A ---r1---> B ---r2---> C
You could represent this directly in RDF, as follows (using Turtle syntax):
#prefix : <http://example.org/> .
:A :r1 :B .
:B :r2 :C .
In a more abstract modeling, you could do something like this:
#prefix g: <http://example.org/graph-model/> .
#prefix : <http://example.org/> .
:A a g:Vertex .
:B a g:Vertex .
:C a g:Vertex .
:r1 a g:DirectedEdge ;
g:from :A ;
g:to :B .
:r2 a g:DirectedEdge ;
g:from :B ;
g:to :C .
The above is just a simplistic example of course, but hopefully it illustrates that this potentially meets quite a few of the things on your wish list.
By the way, if you want even simpler, N-Triples is also an RDF syntax, which is line-based and therefore easy to process in a streaming fashion. It's slightly more verbose than Turtle but it may make file comparison easier.
My thoughts:
What I'm missing is your particular practical purpose/domain.
You mention the generic JSON format next to specific formats (e.g. GraphML which is an application of XML). So I'm left with the question if you do or don't consider making your own format.
Wouldn't having a 'canonical representation that can be used to determine equivalence' solve the graph isomorphism problem?
GraphML seems to cover a lot of your theoretical requirements, so I'd suggest you create a JSON version of this. This would then also cover requirement 6.
Then, you could create a converter between the JSON format and GraphML (and possibly other formats).
For your requirement 7 it again all depends on the practical graph sizes. I mean, nowadays sending up to a few MB to a friggin mobile device is not considered much. A graph of a few MB in (about) any format you mention, is already a relatively large beast with tens of thousands of nodes & edges.
What about Trivial Graph Format:
In a system I Have a list of nodes which are connected like in a normal graph. We know the whole system and all of their connections and we also have a startpoint. All my edges has a direction.
Now I want to draw all of these nodes and edges automatically. The problem is not the actual drawing, but calculating the (x,y) coordinates. So basically I would like to draw this whole graph so it looks good.
My datastructure would be something like:
class node:
string text
List<edge> connections
There must be some well known algorithms for this problem? I haven't been able to find any, but I might be using the wrong keywords.
My thoughts:
One way would be to position our startnode at (0,0), and then have some constant which is "distance". Then for each neighbor, it would add distance to the y position, and for each node which is a neighbor, set x= distance*n.
But this will really give a lot of problems - so that's definetely not the way to go.
By far the most common approach for this is to use a force-directed layout instead of a deterministic one. The gist is that you have every node repel each other (anti-gravity) and have any connected pairs of nodes attract each other. After several iterations of a physics simulation you can get a reasonable layout.
There are many layout algorithms you can use, with vastly different results. The GraphViz fdp (Fruchterman & Reingold '91) and neato (Kamada & Kawai '89) algorithms work, but are rather old and there are much better alternatives. The Fruchterman & Reingold '91 algorithm is also available in Python in NetworkX.
Prefuse provides a ForceDirectedLayout Java class that is pretty fast and good. Hachul & Jünger '05 detail the FM^3 algorithm, which appears to do quite well in practice (Hachul & Jünger '06) and is available in C++ in Tulip.
There are tons of other open source tools to visualize graphs, like
NodeXL (C#), a great introductory tool that integrates network analysis into Excel 2007/2010 (Disclaimer: I'm an advisor for it). Other awesome tools include Gephi (Java) and Cytoscape (Java), while Pajek, UCINet, yEd and Tom Sawyer are some proprietary alternatives.
In general this is a tricky problem, especially if you want to start dealing with edge routing and making things look pretty. You might look at http://www.graphviz.org/ and using either their command line tools, or using the graphviz library to do your layout and get your x,y coordinates within your application.
The graph is arguably the most versatile and valuable data structure of all. I can store single variables, lists, hashes etc., and of course graphs, with it.
Given this, are there any languages that offer inline / native graph support and syntax? I can create variables, arrays, lists and hashes inline in Ruby, Python and Javascript, but if I want a graph, I have to either manage the representation myself with a matrix / list, or select a library, and use the graph through method calls.
Why on earth is this still the case in 2010? And, practically, are there any languages out there which offer inline graph support and syntax?
The main problem of what you are asking is that a more general solution is not the best one for a specific problem. It's just average for all of them but not a best one.
Ok, you can store a list in a graph assuming its degeneracy but why should you do something like that? And how would you store an hashmap inside a graph? Why would you need such a structure?
And do not forgot that graph implementation must be chosen accordingly to which operations you are going to do on it, otherwise it would be like using a hashtable to store a list of values or a list to store an ordered collection instead that a tree. You know that you can use an adjacency matrix, an edge list or adjacency lists.. every different implementation with it's own strenghts and weaknesses.
Then graphs can have really many properties compared to other collections of data, cyclic, acyclic, directed, undirected, bipartite, and so on.. and for any specific case you can implement them in a different way (assuming some hypothesis on the graph you need) so having them in native syntax would be overkill since you would need to configure them anyway (and language should provide many implementations/optimizations).
If everything is already made you remove the fun of developing :)
By the way just look for a language that allows you to write your own graph DSL and live with it!
Gremlin, a graph-based programming language: https://github.com/tinkerpop/gremlin/wiki
GrGen.NET (www.grgen.net) is a programming language for graph transformation plus an environment including a graphical debugger. You can define your graph model, the rewrite rules, and rule control with some nice special purpose languages and use the generated assemblies/C# code from any .NET language you like or from the supplied shell.
To understand why normal languages don't offer such a convenient/built-in interface to graphs, just take a look at the amount of code written for that project: the compiler alone is several man-years of work. That's a price tag too hefty for a feature/data structure only a minority of programmers ever need - so it's not included in general purpose programming languages.