= GSoC 2010 Project Ideas = == `PyLemon` module - a [http://www.python.org/ Python] language binding for LEMON == mentor: Alpár Jüttner === Background === LEMON was written in C++, because this is the only widely used programming language that makes is possible to optimize the running time and memory usage of complex data-structures and algorithms to the extreme. However C++ is a rather complex language, which require deep knowledge of programming, and it's usage is many times complicated. Experimenting with and idea and prototyping solution can be much simpler in modern interpreted and dynamically linked languages. Python is a prominent member of these languages, being easy-to-learn, versatile and extremely productive. Python is also a highly extensible language, which allows programmers to create their own modules in C or C++. === The task === The goal is to create a Python interface module to LEMON's data structures and algorithms (written in C++), thus combine the high efficiency of LEMON with the flexibility of Python. You can find the pre-alpha version of this project in our repository: [http://lime.cs.elte.hu/~alpar/hg/pylemon/] === Application conditions === - knowledge of C++ language - knowledge of Python language or have a tendency to learn it - basic knowledge of graph theory - English language knowledge === Benefits of participating === By taking part in this project, you can highly improve both your C++ and Python skills. In addition, understanding LEMON is a good opportunity to learn more about network modeling, graph algorithms and combinatorial optimization. ---- == Multi-thread support & thread safe graph maps == mentor: Péter Kovács === Background === Most LEMON data structures provides thread safety in the usual sense (i.e. they can be safely created in parallel and the read operation is also safe until no one tries to write it in the same time). There is however a very important exception - ''the default graph maps''. The reason is that these data structures must register themselves at the underlying graph in order to be notified about the changes. For thread safety, a locking mechanism is necessary here to prevent race condition. === The task === - Develop a basic API for the most usual threading building blocks (such as mutex semaphore etc). It must be easy-to-use and should be usable on different platforms and with different threading library. Consider using existing open source library, but any external dependence must be optional - Implement a locking mechanism into the graph event notifiers. === Application conditions === - knowledge of C++ language - English language knowledge === Benefits of participating === By taking part in this project, you can get familiar with the LEMON library, and principles of concurrent programming - a soon to be fundamental paradigm in practical operations research and optimization. ---- == Bipartite graph structures & bipartite matching algorithms == mentor: Balázs Dezső === Background === LEMON contains various data structures for storing undirected and directed graphs and there are matured concepts for them. However, bipartite graphs form a special class of (typically undirected) graphs that needs additional functionalities. These specialities are based on the dividing of the node set into two subsets A and B, for which there is no edge with end points belonging to the same subset. This partition can be calculated by a simple graph search algorithm (BFS) on an undirected graph that is actually bipartite, but the bipartite graph algorithms usually require the partition, so it is worth to store it explicitly. Therefore, we need a special graph concept for the bipartite graphs, that is an extension of the undirected graph concept and we need some bipartite graph implementations. Bipartite matching algorithms are also important to have in the library. The older LEMON versions (0.x releases, up to 0.7) contain implementations of bipartite graphs and bipartite matching algorithms, however, these tools have to be thoroughly revised, reworked and improved to be able to include in the stable 1.x releases. In fact, this task is of high importance for the upcomming release LEMON 1.3. === The task === - Revise the old implementations: - bipartite graph concept, - bipartite graph implementations, - bipartite matching algorithms. - Rework these implementations or reimplement them from scratch, if it is necessary. Related tickets: #69, #168. === Application conditions === - knowledge of C++ language - basic knowledge of graph theory - English language knowledge === Benefits of participating === By taking part in this project, you can get familiar with the LEMON library and you can gain a deep insight into the sophisticated implementations of graph concepts and graph structures in LEMON. ---- == Cairo based graph visualization == mentor: Alpár Jüttner === Background === [http://cairographics.org/ Cairo] is a 2D graphics library with support for multiple output devices, including !PostScript, PDF, and SVG file output and also direct display rendering under various operating systems. [http://lemon.cs.elte.hu/pub/doc/1.1.2/a00134.html GraphToEps], LEMON's current graph visualizing tool creates an Encapsulated !PostScript file by hand. Implementing a similar tool based on [http://cairographics.org/ Cairo] would provide various output formats and easy integration to graphical user interfaces. === The task === Develop a tool that provide similar functionality to [http://lemon.cs.elte.hu/pub/doc/1.1.2/a00134.html GraphToEps] but uses the [http://cairographics.org/ Cairo] library for drawing. In order to achieve further flexibility the following changes should be made compared to [http://lemon.cs.elte.hu/pub/doc/1.1.2/a00134.html GraphToEps]. - The extensive use of named template parameters should be replaced by a mechanism using virtual function calls. (In fact, this will make the code much easier). - The necessary preprocessing of the graph should be separated from the actual drawing, in order to speed up this latter process. Related tickets: #344, #86, #76, #284. === Application conditions === - knowledge of C++ language - basic knowledge of graph theory - English language knowledge === Benefits of participating === By taking part in this project, you will get familiar with the LEMON library and the basic principles 2D rendering and perhaps with GUI design. ---- == Binary graph format == mentor: Alpár Jüttner === Background === LEMON has its own text file format, [http://lemon.cs.elte.hu/pub/doc/1.1.2/lgf-format.html LGF (LEMON Graph Format)] for storing graphs and related data (typically node and arc maps). This format makes it possible to handle graphs in a convenient and flexible way and it can be easily read and written both by hand and by a program. However, combinatorial optimization tasks usually require working with very large graphs, i.e. graphs containing millions of nodes and arcs. Storing such a huge graph in a text format takes a large amount of space (e.g. several GBs), however compact the format is (not to mention complicated structured formats, such as XML). Therefore, it would be quite useful to have a binary graph format that could provide (almost) the same functionalities as LGF but require much less space. In addition, the reading and writing operations could also be made much faster using such a compact binary format. === The task === - Design an appropriate binary graph format. It could be called e.g. LBF (LEMON Binary Format). - Develop convenient functions for reading and writing data in this format (with similar interfaces to the LGF tools). - Develop LGF->LBF and LBF->LGF converter tools. Related tickets: #225, #297. === Application conditions === - knowledge of C++ language - English language knowledge === Benefits of participating === By taking part in this project, you can get familiar with the LEMON library, especially with the LGF related tools.