Patch-Less Fullerenes

All PhD students at the College of Engineering and Computer Science at ANU (of which I am one) had to submit a poster by today for the annual (for the second year running) HDR poster day (unless they’re busy finishing off their thesis, etc.).

I haven’t actually done any research yet since I’m still doing my literature review, so my poster was on what I will be doing once I’ve finally read enough papers on edge contractions, etc. in graphs. The focus will be on generating fullerenes (or at least the combinatorial representation of them) with a new algorithm that will hopefully be better than the current standard by Brinkmann and Dress which works by stitching together “patches” (hence the cheesy title of my poster). The new approach (which doesn’t seem to have any non-paywall versions available) uses expansion operations to recursively build fullerenes up from smaller ones.

A copy of my poster can be found here. It took me a week to do, but it wasn’t all that bad to have a week’s break from reading papers…

And if anyone is looking for vector image visualisation of a C60 buckyball, the one that I made (since I couldn’t find one and spent a weekend playing with different chemical visualisation tools until I managed to make a decent looking one) here is a PDF version (since WordPress won’t let me upload SVGs; if you want an SVG contact me and I can send it to you, or just import this into Inkscape).

Haskell, Uni

Now @ ANU

I’m now in my fourth week of a PhD in Computer Science at the Australian National University under the supervision of Professor Brendan McKay (of nauty fame). My topic is as yet still not completely defined, but at the moment it is to do with comparison of graph generation algorithms.


In January this year, I presented a paper on my SourceGraph program at the 2010 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM), a reprint of which is available here. For those of you who are interested, the slides are used (which were heavily edited the night before I gave my talk!) are also available. I would have made these available before now but as soon as I arrived back in Australia I was busy getting ready to move down to Canberra, and I only obtained internet access last week.

The experience was interesting: not only was this the first time I have presented at a professional conference, it was also the first time I had even attended one. What made it even more interesting was the large proportion of people who presented there who (like myself) were not from the actual targeted field (e.g. Florian Haftmann who presented a paper on Isabelle and Haskabelle is from a theorem-proving background).

I’m still working on SourceGraph (if you compare the paper to my Honour’s thesis you should be able to spot the improvements it has already); however, the fact that I actually have university work I’m meant to be doing is proving a hindrance.

Other Projects

Generic graph class

Some people have expressed interest in whether or not I’ve gotten anywhere on my generic graph class proposal. The answer is that I have a rough-and-ready form of one based upon initial discussions I had with Cale Gibbard that uses associated types to define various types such as the vertex type, vertex label type and arc label type. However, the main stumbling block at this stage is that I wanted to add a sub-class dealing with “mappable graphs”, i.e. those graph types that support applying a mapping function over the vertex and arc labels. The problem is, superclass equalities have not yet been implemented within GHC as of 6.12 (but maybe 6.14 will have them). In any case, if anyone is interested I can send them the current messy version, but even without the mappable graphs class it still requires at least GHC 6.10 for associated types support.


Noam Lewis (aka sinelaw) had asked me to add functionality to augment a list of DotGraphs using a single dot (or related command) process; however it turns out that for more than five DotGraphs this takes longer than doing each one individually. As far as I can tell, the problem relates to the rendering of the pretty-printed list of DotGraphs. As of now I’ve rolled back support for this, but I may try rendering to lazy text values, which will also let me avoid encoding problems by forcing usage of UTF-8.

I’ve also been asked by several people to add support for record labels; I’m doing so, but I got side-tracked into implementing proper support for HTML-like labels, which involves a lot of manual experimentation to determine what is valid syntax, etc.

Another area which involves manual experimentation: proper parsing of nodes and edges. Up until now, the library has assumed that there is at least a semi-colon between each individual statement in Dot code. This is not actually the case (which I found out when trying to parse the output of ghc-pkg dot), but when I tried to change this to assuming that each line ended in either a semicolon or a newline (I’m a mathematician, so or implies both as well!) then the edge a -> b was instead parsed as just the node a (with a parsing failure for the rest of the input). What makes it even better is that this is a valid Dot graph:

digraph { a b -> d c -> b -> a [color="red"] }

Now, how the hell am I meant to sensibly parse that?!?!? (Note: it isn’t the multi-edge c -> b -> a that’s the problem; the library can already cope with that; it’s just being able to tell when a particular statement ends and another begins). Bonus points if you can tell just by looking at it which edges are coloured red.


I’ll get around to adding re-register support, etc. to haskell-updater someday, I promise!

Gentoo, Haskell, Uni

Past, Present and PEPM

I was planning on posting semi-regularly here, but I’ve been procrastinating way too much. It’s not that I don’t have anything to write about, it’s just that by the time I get on the computer I can usually find better things to do 😉

Anyway, this is kind of a summary update about what I’ve been working on and what I’m going to be doing.

The Graph Trifecta

I’m responsible for three graph-related Haskell packages on HackageDB: graphviz, Graphalyze and SourceGraph. These three packages are interrelated: graphviz is used by Graphalyze which is in turn used by SourceGraph (which also uses graphviz).


The graphviz provides bindings to the Graphviz (note the differences in capitalisation) suite of tools for visualising graphs. Well, OK, I’m not actually binding the actual C library, just generating the appropriate representation into Graphviz’s Dot code and calling the appropriate tool, but close enough. I’m hoping that it will eventually become the definitive way of using Graphviz in Haskell (as opposed to all the other packages that either provide “bindings” to Graphviz or do so internally). It does have some limitations, however:

  • Only supports conversion to/from FGL graphs for now, as there’s (as-yet) no standard way of considering an arbitrary graph data structure.
  • Does not support arbitrary placement of Dot statements but follows a specific order; I did ask on the Haskell mailing lists if anyone wanted this feature but was told resoundly “no”; I might add it as an option in a future release however.

It seems every release of graphviz introduces an API change. Well, OK, not all; there are bug-fix releases, etc., and I use the Haskell Package Versioning Policy (PVP) so releases that do break the API are obvious. Also, after the 2999.5.0.0 release, I’m trying to keep the API changes to a minimum whilst still improving the library. After all, it’s all part of the process of making A Better Library (TM) for everyone 😉

What I’m working on at the moment for graphviz is improved support for interaction with the actual Graphviz tools in how you call them and how you choose which format they’re created in. Rather than just indicating if the operation was successful or not and printing any error messages to stderror, it’s now using the Either datatype to return the actual error if there is one. The code isn’t perfect (a full disk exception will currently freeze it, etc.) but it’s getting there. I’ve also improved the image output support by allowing the programmer to use any (non-deprecated) image type that Graphviz officially supports and not just those that I happened to have had available on my system when the first version was written (note that there might be other types as well that aren’t listed in the official documentation; my install has support for a gv output type and I have no idea what it is); there is also the ability for the library to automatically add the correct file extension to the output filename. Canvas (i.e. make a window with the graph visualisation rather than create a file) output types are now also treated separately.

I’m also working on adding QuickCheck support to ensure that parse . print == id for all supported types. Note that it isn’t valid to consider this the other way round: graphviz doesn’t support arbitrary placement of statements in the Dot code, and it parses more liberally than it prints. This should hopefully find any lingering bugs I’ve got lying around in the parsing and printing side of things. The next step would then be to ensure that any generated Dot code is then able to be processed by Graphviz using the Dot (why does Graphviz have to call so many things “Dot”?) output type to add position information, etc. and have that fully parseable.

Also, documentation is gradually being improved; I’m never intending that users will be able to completely ignore the official Graphviz documentation; however, I’m trying to make it as obvious as possible the differences of opinions/terminology/etc. between Graphviz and what graphviz supports, as well as providing broad overviews of the different options and giving links to the appropriate upstream documentation.


Graphalyze was the main focus of my mathematics honours thesis last year. It provides a library to use graph-theory to analyse the relationships in discrete data sets. Nowadays, it mainly serves to do the heavy lifting for SourceGraph.

Work on Graphalyze is mainly to add extra graph algorithms that I want for SourceGraph. I’m also wanting to eventually replace the current reporting framework with a pretty-printing based one; possibly removing the pseudo-option of using something apart from Pandoc and just making it the default; this will definitely necessitate a licensing change for most of the library however (which I have no problems with, and it doesn’t appear to be used by anyone else…).


First of all, I was urged (by people who shall remain nameless unless they say its OK) to submit a paper based upon SourceGraph to Partial Evaluation and Program Manipulation 2010 (PEPM) which is going to be held in Madrid next January. I didn’t expect to get it expected (to be honest, there’s nothing that I think is that interesting/new in SourceGraph for the moment except for possibly the overall concept), but it gave me a figurative kick up the proverbial to actually update SourceGraph (which was my first ever real released Haskell program… 😮 ) and I thought that the actual process of writing the paper would be good practice. It turns out however that I was chosen, which resulted in a mad rush to update the paper (many thanks to quicksilver on #haskell for fixing up my Haskell terminology). So I now find myself preparing for my first ever real academic conference, let alone the first one that I’ll be presenting at! What makes the situation even more interesting is that I’m currently not a student (more on that later) and so the financial aspect will be interesting… I’ll be putting a version of my paper up here as soon as I fully understand the hoops I have to jump through to do so.

Whilst SourceGraph was just a sample application of Graphalyze in my honours thesis, it was why I’d originally thought up the topic; my supervisor convinced me to make the application aspects more general by splitting out the graph-theory side of things into a library and having several sample usages, of which I only ever ended up doing the one (mainly due to time constraints). It is now the driving force behind graphviz and Graphalyze (well, OK, users sending me bug reports/feature requests and my own sense of pride do help with graphviz; the latter was what prompted the re-writing of the printing/parsing layout whilst I was meant to be on holidays overseas visiting family…) and the focus (transitively or otherwise) of most of my Haskell hacking at the moment.

Anyway, I’m currently trying to improve the quality of the output produced by SourceGraph in terms of usage (by adding command line parameters) and in what kind of analyses it produces. I have kind of shot myself in the foot, however, as I’ve already updated it to use the as-yet-unreleased 1.8 series of Cabal, so I can’t release it (not that it’s anywhere close to being in a releasable state) until Cabal-1.8 is available…

Haskell in Gentoo

I’m going to do a proper post over on the official Gentoo-Haskell blog later on about most of this, but here’s a brief rundown on what I’ve been doing (along with kolmodin, trofi, etc.):

  • I’m still not an official dev, as I don’t have time/can’t be bothered (pick whichever you think is more accurate :p ) to finish off the dev quiz; I still help out on the IRC channel, answer (but not close) bugs on bugzilla, etc.
  • I’ve been doing some “spring-cleaning” in the overlay to try and remove old, unused packages (and versions of packages). I’m defining “unused” as “the version in the overlay is out of date, no-one has complained about it being out of date and I can’t be bothered checking through all the dependencies, etc.” 😉
  • Trying to get GHC 6.12 RC1 to work; whilst I’ve managed to build an x86 binary bootstrap package, I’m not able to actually use it to bootstrap, and if I try and install that with USE="binary", then it appears our hack for not installing haddock with GHC doesn’t seem to work anymore :s
  • haskell-updater has been updated to work with GHC 6.12/Cabal 1.8 \o/ . Of course, I can’t actually test this out fully as I’m not able to install 6.12 here… The underlying code has also been rewritten to make it easier to add extra options down the track.


After I finished my maths honours last year, I had been hoping to study at the University of Edinburgh this year (starting in September, which would have been convenient for going to ICFP), but whilst I was accepted I was unable to obtain any funding 😦 As such, I’ve been either working at the University of Queensland (doing some casual sysadmin-ing as well as developing material for and helping to run the new SCIE1000 subject) or working on a few odds and ends at home (that is, the projects mentioned above) all this year.

Because my dreams of studying overseas have been dashed, I’ve now applied to study at Australian National University in Canberra under the supervision of Professor Brendan McKay. Whilst I haven’t been officially accepted, I’ve been told that I’m guaranteed a spot (and at least some funding) due to my academic results for honours last year. I’ll be working on combinatorial algorithms, so nothing officially Haskelly in nature (but I’m intending on doing most – if not all – of my coding in my favourite programming language).


I mentioned previously that I’d be going to PEPM next year… will anyone else from the Haskell community be there (or at any of the other conferences associated with POPL)? I’ve as yet only had the pleasure of meeting one person (dibblego), and it’d be great if I could put some faces to some of the other names I see in #haskell or on the mailing lists…

That’s all folks

In case anyone cares, this is what I’ve been up to and am planning on doing for the most part. This blog post on the main was to try and get me writing here more often, as well as an attempt to stifle Joe Fredette’s continual complaints of lack of Haskell Weekly News material because I haven’t released anything recently 😉 So Joe, go ahead and write about this! :p