#include <boost/config.hpp>
#include <iostream>
#include <string>
#include <boost/graph/edmonds_karp_max_flow.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/read_dimacs.hpp>
#include <boost/graph/graph_utility.hpp>

Here are the basic includes for the sample program.

// Use a DIMACS network flow file as stdin.
// Example file found inline at: http://lpsolve.sourceforge.net/5.5/DIMACS_maxf.htm
// Usage: max_flow < max_flow.dat
int
main()
{
  using namespace boost;

  typedef adjacency_list_traits<vecS, vecS, directedS> Traits;
  
  // define our graph with so-called internal properties
  typedef adjacency_list<listS, vecS, directedS, 
  // vertex properties
    property<vertex_name_t, std::string,
    property<vertex_color_t, default_color_type> >,
  // edge properties
    property<edge_capacity_t, long,
    property<edge_residual_capacity_t, long,
    property<edge_reverse_t, Traits::edge_descriptor> > > 
  > Graph;

  Graph g;

Strictly speaking, the graph itself is restricted to the first three template parameters. The first two parameters tell you how the edges and vertices are represented. In our case, they are both stored in std::vectors – the first two vecS are special types defined in Boost for that. There’s the usual tradeoffs to consider and it’s nice to not have to worry about it. The last parameter tells you if you have a directed or undirected graph – again, using a special Boost type.

All of the properties following the first three are internal properties, which can basically be thought of as associated data specific to either the vertices or the edges. They are internal properties because they are attached to the graph itself, but Boost gives you the option to keep it external if you want. There are a bunch of graph predefined properties that you only bring in when you run an algorithm that makes use of them. In particular, Edmonds-Karp max flow makes use of vertex colors internally.

  // make references to the internal properties of the graph
  property_map<Graph, edge_capacity_t>::type 
    capacity = get(edge_capacity, g); 
  property_map<Graph, edge_reverse_t>::type 
    rev = get(edge_reverse, g); 
  property_map<Graph, edge_residual_capacity_t>::type 
    residual_capacity = get(edge_residual_capacity, g); 
  property_map<Graph, vertex_color_t>::type 
    color = get(vertex_color, g); 

  Traits::vertex_descriptor s, t;

We get references to some of the properties for passing to the algorithm. In this way, we’ll retain the colored vertices and can get what we really want out of max flow, which is the cutset.

  // read in the graph from stdin
  read_dimacs_max_flow(g, capacity, rev, s, t);

  long flow = edmonds_karp_max_flow(g, s, t,
    capacity_map( capacity )
    .reverse_edge_map( rev )
    .residual_capacity_map( residual_capacity )
    .color_map( color ));

Here we load in the graph from a dimacs file. Go to the site in the header comment to get a sample file. We pass in all of our relevant data structures to edmonds_karp_max_flow, the last argument being all of the property maps bundled together using those helper functions that chain together.

  std::cout << "number of vertices: " << num_vertices(g) << std::endl;

  std::cout << "c  The total flow:" << std::endl;
  std::cout << "s " << flow << std::endl << std::endl;

  std::cout << "c flow values:" << std::endl;
  graph_traits::vertex_iterator u_iter, u_end;
  graph_traits::out_edge_iterator ei, e_end;

  const char* name = "abcdef";
  for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
  {
    for (boost::tie(ei, e_end) = out_edges(*u_iter, g); ei != e_end; ++ei)
    {
      if (capacity[*ei] > 0)
        std::cout << "f " << name[*u_iter] << " " << name[target(*ei, g)] << " "
                  << (capacity[*ei] - residual_capacity[*ei]) << " "
                  << "(" << residual_capacity[*ei] << ")" << std::endl;
    }
  }

Above is just printing out the flow. Notice how vertices returns a pair of vertex iterators. boost::tie is a macro that lets you assign multiple variables at the same time, like assigning tuples in Perl. You can see how the property maps work – they map the edge or vertex descriptor to the property associated with that descriptor.

  std::cout << std::endl << "the min cut:" << std::endl;
  for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
  {
    for (boost::tie(ei, e_end) = out_edges(*u_iter, g); ei != e_end; ++ei)
    {
      if (color[*u_iter] == color[s] && color[target(*ei, g)] == color[t])
      {
        // damn yeah
        std::cout << name[*u_iter] << "-" << name[target(*ei, g)];
        std::cout << " (" << capacity[*ei] << ")" << std::endl;
      }
    }
  }

Finally, this is how to actually get the edges that make up the cutset from the colored vertices. The vertices will be colored based on which partition it ends up being on, and the cut edges are precisely the ones that bridge between the partitions ie. the ones that go from a vertex of one color to a vertex of the other color.

Thoughts

I really had a tough time looking for the usable types and the interfaces to these types. The above program was mostly part of an example program in the documentation, tweaked to include the color map and the code that uses the information to extract the edges. It took my the longest time to figure out how to pass in the color map to the algorithm that I wanted it to use. Even then, I wasn’t sure that I would get something useful in return and it just took rounds of attempted compiles and runs to see what all of the code actually does. I feel like this was much harder than it should have been, but I wonder if it’s something that someone with experience with templated C++ would have an easier time with. It just seems like there’s nothing like a straightforward equivalent of the Java API.

Well let’s post this before I go crazy from the way the editor eats the templates in the C++ code when I toggle between visual and HTML editing.

• Intel i7 950
• Asus P6X58D-E Motherboard
• OCZ Gold PC12800 DDR3 Triple Channel Memory
• OCZ Vertex 60GB SSD
• Thermaltake TR2 RX 750W PSU
• Scythe Mugen SCINF-1000 Heatsink

Thanks Tuan for the help!

Just running :mksession in Vim will create a snapshot of your tab and window layout etc. and save it in a session file. You can check the help on the command for the exact details. Here’s a convenient mapping that lets me hit ,wq and have all files written and tabs saved in a session file.

let mapleader=","
:map <leader>wq :wa:mksession!:qa
:map <leader>ls :source Session.vim

So my map leader is the comma. Hitting that puts Vim in a mode where if you complete one of the map rules, the corresponding command will be executed.

The first command executes three commands. First, it writes all files that are open. Then it creates a session file into Session.vim in the current working directory. The exclamation mark means overwrite Session.vim if it exists already. Last, it exits out of Vim by closing all open tabs.

The second command sets up Vim from the Session.vim in the current working directory. You run this the very first thing you do when you open Vim in the directory where your work is at, and your workspace is restored to exactly the way you left it.

I guess having the map leader is what makes this effective because it opens up a whole new range of keystrokes for defining new mappings. Some other ideas: toggle paste mode when pasting from the system clipboard. I always have to type :set paste and :set nopaste whenever I need to bring stuff into Vim through the clipboard without having the indentation go haywire, but you now I’ve got this in my rc file:

set pastetoggle=pp

Any other ideas people have? Did you already know about this? I’m constantly learning new stuff about Vim – that is, whenever I’m not just using it to do work and actually poking about the documentation and configuration.

On the other hand, I made a good start programming on my sweet new desktop – I owe a shout-out and some details about my new desktop on Wednesday. It took a while but I figured out how to find the edges in a min-cut of a graph in C++ using the Boost library. It was *such* a headache trying to figure things out from the docs and making sense of the generic code. I think I’ll give it some time to sink in but I’ll definitely write about how its done, my impression of BGL, and thoughts on graphs in general by Friday. Along the way, I found yet more cool stuff with vim, which I’ll write about on Monday.

Winter quarter starts here at UC Davis tomorrow. Aside from taking courses in algorithms, network theory, and neuroimaging, I’m going to be a TA for introductory C programming. The prof said besides teaching the language, he also wanted to introduce applications, both old and new, to sort of motivate/reinforce the learning. It’s an interesting question: what’s new and interesting that people are doing with C? This is an ongoing question to think about and try to answer this quarter.

If there’s some new year’s resolution that I’ll take seriously, it’s to read more code. I’m going to renew my efforts in following some interesting open source projects and mailing lists, follow some bugs, and read some code that way. I don’t know yet what I’ll write about as commentary, but there’s bound to be interesting things worth mention.

Here are a few notes that I gathered in a flash (and which you can gather by following the links above):

• Neurons are modeled by perceptrons
• Perceptrons = summing junction + nonlinear element
• Summing junction – dot the input vector with coefficients (state)
• Nonlinear element – take that dot product, map it under the sigmoid function for your output
• You hook up a bunch of these perceptrons into a DAG (basically a trellis without the one input node restriction) and call it a neural network
• You train the neural network by putting in some input signals, compare the generated output with an expected output, and perform backpropagation to adjust the coefficients

With that high-level review, I’m thinking that the tutorial just got through hooking up a small neural network with 1 input layer, 1 hidden layer, and 1 output layer, and training it. I’m not sure the code that I have has it correct because, well, where’s the expected output? -_- And how to use it once it’s trained, I’m not exactly sure. But I thought I’d put the code up so that I could look at some of the code again now that a significant amount of time has passed and I’ve learned some other related things that might help this make more sense. It sort of does, from a high-level point of view, but I couldn’t explain the details of how the neural network is actually adjusting a hyperplane to classify an input vector; I didn’t work any proofs, I just wrote some Erlang.

Just a thought: If the neural network is just doing high-dimensional gradient descent, why can’t we just solve the problem and implement gradient descent? I guess a solution in the form  of a neural network is somehow more general? Or maybe it’s simpler: you’re really just feeding some training data to the network and then using it to predict new data. I don’t know. It’s an interesting approach though.

First, a little bit about our setup: we have a server where we have our application deployed, but we also have active development going on right on that server. This is convenient and is a typical workflow for web projects: you’ll make and upload edits to see the changes on the server immediately. I have a local server set up on my laptop that I’ll work on, which saves me the hassle of the upload, and in this case turns out to be nice in that I’m not inadvertently clobbering work on the remote server.

Every once in a while, I’ll need to pull in the latest changes and also push out my work as well. For the longest time, I didn’t have a great way of doing this. Initially, I was just using FTP, at times to cherry-pick files and other times just batch downloading the whole project tree. Needless to say, this is a big waste of time and involved more point-and-click than I could stand. It also doesn’t give a good feeling about being in sync at all.

Sync? Great idea, we can use rsync! We do have shell access after all. The next step came when I wrote an rsync command to pull the files I care about from the remote server to my machine. Rsync is nice because it just transfers differences, so it’s nice and quick. The problem is that it clobbers old stuff, and for a while I was using a separate folder with rsync apart from my working folder and manually diff/patching. This also got annoying.

But wait a minute, I don’t have to worry about clobbering code, I could just create a branch in git and pull the changes into that branch. My own branch will be untouched and I can use git checkout to switch between branches. From there, I can merge that branch with my main working branch!

For example, the team meets at 5pm to continue work on the project. At that point, I will create a branch for myself do work on, and my partner will go about his work on the remote server. When we call it a night later on, I create another branch from the initial 5pm commit and pull in changes from the server using rsync.

At this point, git recognizes the fork, and when you issue a git merge command, git will do its best to merge changes, presenting a list of conflicted files if it can’t resolve them itself.

atsui@atsui-mmx:~/web/letswoosh$ git branch
* alex
  master
  parris
atsui@atsui-mmx:~/web/letswoosh$ git merge parris
Auto-merging app/plugins/woosh/controllers/events_controller.php
Auto-merging app/plugins/woosh/models/event.php
CONFLICT (content): Merge conflict in app/plugins/woosh/models/event.php
Auto-merging app/plugins/woosh/views/events/nearby_events.ctp
CONFLICT (content): Merge conflict in app/plugins/woosh/views/events/nearby_events.ctp
Auto-merging app/views/elements/tag_form.ctp
CONFLICT (content): Merge conflict in app/views/elements/tag_form.ctp
Automatic merge failed; fix conflicts and then commit the result.

I’ll go through the files, clean up the conflicts, add them back to git, and commit the changes, after which the two branches are successfully merged.

The benefits are clear: no manual diff/patch business, the ability to check out any past commit later on, and a pretty graph to look at. After doing things a pretty hard way, I guess I learned a lesson about using git.

This was really helpful for understanding merge:
http://github.com/guides/pull-requests

Back to the problem, another guy in my room took a different approach from mine and implemented breadth-first search. Basically, you expand outwards uniformly from the source node searching for a destination node. The advantage is that once you find the destination node, you have the shortest path and are done. Sadly, a mistake in the implementation ruined this good approach.

It took me a while to figure out that the guy had implemented his own queue for BFS, using a fixed-size array and pointers to the front and back.  The terminating condition in this case would be to check whether the front and back pointers were the same, ie. the queue is empty. It wasn’t until I could run the program in a debugger that I noticed the program was segfaulting due to the front pointer extending way beyond the upper bound of the array. However! I didn’t recognize this for what it was and decided to patch things up by turning the queue into a circular queue.

This fixed the problem for the grid-type graphs that the problem was giving out, but it left me wondering about a fixed queue size that could handle all cases. In the worst case, BFS will visit every node in a graph once, and in theory, it’s possible to queue up all of the nodes at the very first step. The program that I “fixed” with a circular queue was using a fixed size queue with a size that was an order of magnitude lower than the maximum number of nodes that could be dished out by the problem. I was definitely lucky that the number of nodes enqueued at any one time never exceeded the magic number being used to size the queue.

So it’s interesting to think about what that running number – the number of nodes enqueued at any given time during BFS – represents and whether we are able to give an upper bound for it. At any given moment, it gives the size of a “cross-section” of the graph. I guess without knowing about the structure of the graph, you can’t really assume much and so you have to bound the queue by the total nodes in the graph. The graphs in this problem were 4-regular, ie. every node has 4 adjacent nodes, and since the program was passing, this upper bound is definitely an overestimate.

I guess the moral of the story is to use the data structures provided by your local library, because thinking about upper bounds can be a deal breaker, and implementing your own data structure on the fly is error-prone and definitely cost this guy a hundred and some points.

Sass comes with the haml Rubygem, and it’s basically an extension to CSS, giving it things like variables, mixins – which are kinda like macros, and ability to generate nicely formatted CSS or compressed CSS for efficient use of bandwidth. Sass can then be set as a daemon to watch a project directory, compiling Sassy CSS files (as they call it) into standard CSS files whenever a change is made. Installation was as simple as gem install haml, assuming Ruby is set up on your server. It wasn’t on ours initially, but just clicking into Rubygems on the CPanel triggered the server to set it up automatically.

XHP took a little more work to get (and still doesn’t seem to work 100% – one post-build unit test failed… however, PHP was able to load the module and we’re making good use of it). First of all, the site specifies some prerequisite software – treat the versions as minimum requirements. re2c was one necessary package that wasn’t readily available in the required version (0.13.5 – we had 0.13.4 on the server but XHP accepts no less) as an RPM. So I had to hit up Sourceforge for the source RPM and compile it. This wasn’t too bad. The workflow is basically as follows:

1. rpm -ivv <name of source rpm>. This seems to stage the resources in an area for building and extracts a specfile, which is a Makefile of sorts. The -vv option will trigger verbose output, which should tell you where the specfile is.
2. rpmbuild -bb <name of the specfile>. Run this after you cd to the directory where the specfile is. This will start the build process, which hopefully runs without a hitch and produces an RPM at a secondary location.
3. rpm -i <name of compiled rpm>. The installed software should be available immediately.

Compiling was easy, but the post-build unit test refused to run because PHP had safe mode enabled. Apparently, it was compiled into the PHP on the server, so a rebuild was necessary. CPanel has a nice point-and-click configuration for this as well, though Apache needs to be rebuilt as a part of this as well. After that, do a make install and add extension=xhp.so on a new line in your php.ini. Your site should be good to go. Also, one useful configuration option to have is xhp.idx_expr=1, which enables you to index arrays returned from function evaluations right away.

This stuff all took a while to figure out, but in the end, we added two awesome tools to our disposal, which keeps the spirits high and the developers developing!

For example, I have a blanket configuration for inserting 4 spaces for tabs in any file I type, because tabs are evil:

set shiftwidth=4 softtabstop=4 expandtab

But this is a pain when editing Makefiles, where tabs are a necessity for build rules.  You end up entering explicit tabs with <CTRL+V> <TAB>, which is tedious.  Instead, you can make vim know to use real tabs in Makefiles:

autocmd BufEnter Makefile set sw=8 sts=0 noet

Another example is for creating html files. It’d be nice to have a skeleton file that includes a strict doctype and the proper content type all ready to go.   Also, nesting can get real deep real quick so an adjusted shift width would be nice.  This does the trick:

autocmd BufNewFile *.html 0r /path/to/your/template.html
autocmd BufEnter *.html set sw=2 sts=2 et

Basically, creating new html files will source the template html file, and editing any html file will adjust the indent size to 2 spaces to save on horizontal space.

There are lots of different hooks where you can make use of autocmd. Type :help Buf and hit <CTRL+D> to see a lot more buffer-related hooks.

So I searched for ‘better cygwin terminal’ and the first result tells you exactly how to do it.  Basically, you go into C:\cygwin\Cygwin.bat, replace the line that reads:

bash --login -i

With:

start rxvt -sr -sl 10000 -fg white -bg black -fn fixedsys -fb fixedsys -tn cygwin -e /bin/bash --login -i

Okay, I realize it’s kinda lame to re-blog top Google results, but more people should know about it – no one deserves to be squinting at a 80 by 25 window that you can’t even copy and paste from, nor can you scroll up and down on, nor can you resize.  The command line rocks, and people might never realize it experiencing it through Cygwin.

Also, I found that manpages were scrambled with special characters appearing as garbage in rxvt.  A fix for that is to add the following to .bashrc:

export LANG=C.ASCII