/Visualisation/GraphDrawing/plans/general.hpp
C++ Header | 155 lines | 4 code | 3 blank | 148 comment | 0 complexity | 1c6a43551f235a4102771f059bcc2711 MD5 | raw file
- // Oliver Kullmann, 26.12.2005 (Swansea)
- /* Copyright 2005 - 2007, 2008, 2009 Oliver Kullmann
- This file is part of the OKlibrary. OKlibrary is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public License as published by
- the Free Software Foundation and included in this library; either version 3 of the
- License, or any later version. */
- /*!
- \file GraphDrawing/plans/general.hpp
- \brief Plans for the graph drawing module (as a whole)
- \todo Update namespaces.
- \todo Graphics library
- <ul>
- <li> The fundamental problem is to determine a suitable graphics library
- (or just relying on a graph-library with drawing-capabilities, or on a
- special graphs-visualisation library).
- </li>
- <li> Possibilities:
- <ol>
- <li> Qt : very intrusive, and thus perhaps not the right choice </li>
- <li> OpenGL in the form of the Mesa library: Perhaps this is suitable.
- </li>
- <li> Perhaps easiest is FLTK http://www.fltk.org/ . </li>
- </ol>
- </li>
- <li> This graphics library must offer the following functionality:
- <ol>
- <li> a window with graphical elements can be created; </li>
- <li> graphical elements can be handled as objects, and placed on the
- canvas using coordinates; </li>
- <li> graphical elements include at least pixels, points (in various sizes)
- and lines; it should be possible to vary their appearance (including
- giving them colours), and possibly these elements can be moved; </li>
- <li> regarding drawing big trees, we need to zoom in and out easily. </li>
- </ol>
- One should play around with Mesa and FLTK to see what they can, and to
- estimate the quality of these libraries.
- </li>
- <li> At least at the Maxima/Lisp level, Gnuplot should also be investigated.
- </li>
- </ul>
- \todo Graph visualisation library
- <ul>
- <li> http://www.ogdf.net/doku.php looks like a
- reasonable choice; but apparently not much newer developments. </li>
- <li> Then perhaps we don't need the graphics library? </li>
- <li> See "Graph drawing" in
- Buildsystem/ExternalSources/SpecialBuilds/plans/Graphs.hpp. </li>
- <li> Also some of the general graph libraries (see "General C++ graph
- libraries" in Buildsystem/ExternalSources/SpecialBuilds/plans/Graphs.hpp)
- have graphics-capabilities. </li>
- </ul>
- \todo External libraries / programs:
- <ul>
- <li> there is this C-program especially for drawing large trees XXX </li>
- </ul>
- \todo Concepts
- <ul>
- <li> Concepts for rooted oriented trees and for graphs are needed. </li>
- <li> For graphs the Boost graph library is not optimal, but not too bad.
- </li>
- <li> See "Graph drawing" in ComputerAlgebra/Graphs/Lisp/plans/general.hpp.
- </li>
- <li> Important for communication is to get an overview on
- graph-file-formats, both for "abstract" and for "drawn" graphs.
- <ol>
- <li> See "Input/Output" in Graphs/BoostSupport/plans/general.hpp. </li>
- </ol>
- </li>
- </ul>
- \todo Applications
- <ul>
- <li> Likely the different sub-points deserve their own modules. </li>
- <li> SAT solvers output the search tree in xml format; the tree is drawn,
- and at least one selected value labeling the vertices is visualised using
- some colour scheme; see GraphDrawing/plans/Trees.hpp.
- <ol>
- <li> The information for each node varies from solver to solver, so we
- need several xml-fields. </li>
- <li> Possible information is
- <ul>
- <li> The branching variable. </li>
- <li> Number of r_k-reductions for available k. </li>
- <li> Number of pure literals. </li>
- <li> Autarkie reductions. </li>
- <li> Measures for the clause-set. </li>
- <li> Time needed to process the node. </li>
- </ul>
- Should we treat this information all as numerical? The branching variable
- is different --- here we need the precise value (and also a name is
- attached to it).
- </li>
- <li> Besides node-labellings with numerical values we also have
- edge labellings:
- <ul>
- <li> The distances for the branching (the one used to select the
- branching, and also additional ones). <li>
- <li> The probability in the probability distribution corresponding
- to the branching tuple (see
- Heuristics/StatisticalAnalysis/plans/BacktrackingProbing.hpp) </li>
- <li> the optimal probability (from the canonical probability distribution
- of the tree; see OK's SAT-handbook article on heuristics) </li>
- <li> The estimated probability for satisfiability (for choosing the
- first branch; see
- Heuristics/StatisticalAnalysis/plans/SatisfiabilityPrediction.hpp).
- </li>
- </ul>
- As a non-numerical labelling we have the branching literal.
- </li>
- </ol>
- This all for backtracking-solvers; conflict-learning is difficult. </li>
- </li>
- <li> The various (multi)graphs associated with CNFs should be visualised
- (static snapshots, and also dynamic simulations). </li>
- <li> For CS-232 a visualisation of the graph_traversal algorithm is needed,
- starting with a drawing of some graph, where first all vertices and edges
- are black, and then stepwise vertices get marked red, and edges are
- blinking if they are just examined, yellow if they are in the buffer,
- green if the are tree edges, blue if they are back edges (perhaps dashed as
- long as they are still in the buffer). At the end every edge made the
- transition from black through yellow to either green or blue. </li>
- <li> For CS-342 a backtracking tree labeled with clause-sets would be useful
- (possible output in Latex-format). </li>
- </ul>
- \todo Conversions
- <ul>
- <li> It should be possible to create ps-, png- and Latex-files from the
- drawings. </li>
- </ul>
- */
- /*!
- \namespace OKlib::GraphDrawing
- \brief Tools for drawing graphs and trees
- */
- namespace OKlib {
- namespace GraphDrawing {
- }
- }