Testing hard algorithms

Programming is hard. Various techniques help simplify programming, but sometimes the only way to implement something is to think a lot while writing a thousand lines of lightly-tested code, then put the code through a diverse set of tests until you're not longer worried that it's going to fail in unexpected ways. I wrote a long, reflective essay on testing hard algorithms, using my recent MCS work to provide structure.

Topologically non-planar molecules

Chemists and mathematicians interpret "non-planar" differently. Very few small molecular graphs are non-planar, in the mathematical sense. Still, they do exist. In this essay, I managed to find some in the PubChem database.

Maximum Common Substructures and fmcs

Here's the place to comment about my posts related to my maximum common substructure algorithm, fmcs tool based on the algorithm, and MCS benchmarking. The relevant essays are:

• MCS background
• fmcs - find the MCS of a set of compounds
• Finding the MCSes for the ChEBI ontology
• Some analysis information in Testing hard problems

f2pypy

I posted about f2pypy my mini-project to make a new backend to f2py which generates a ctypes-based extension module for Python. The goal is to see if that is a viable path for PyPy support of the existing shared libraries already wrapped by f2py. I think it is.

Feel free to comment!

Where free software and peer-review software differ

In this essay I point out while free software and scientific peer-review have many characteristics in common, they come from different philosophies. There are requirements for free software (free ability to redistribute modified code to anyone) which are not essential to effective peer review, and there are requirements for effective peer review (getting access to the source code in order to evaluate it) which are directly contrary to the free software ideals of the GNU project (which lets you distribute free software for any price you may wish).

Here is the place to leave comments about that essay.

Code review

I believe the literature shows that code review is a effective way to find defects in software and to promote knowledge transfer. I think it's easier to put into place than pair programming. Unfortunately it's also socially stressful.

In my essay on code review I outline some of ways I've done code review and some reasons that people don't do it.

I want to promote the use of code review in general, and also more specifically in cheminformatics. I'm not sure how. I described a few in that essay. If you have more, let me know.

Dealing with SSSR

Here's the place to leave comments about my "Dealing with SSSR" article. In it I describe my experience in trying to develop a toolkit-indendent means of specifying some of the PubChem bits which require ESSSR. I concluded saying that I couldn't - without reimplementing ESSSR myself for each toolkit - handle those bits so I would be ignoring them.

I also wondered why people use SSSR, and how well they've tested their SSSR-based algorithms, including testing in the face of differing atom order.