Fractions can be confusing.  But there there are a few simple rules which encompass everything you could ever want to do with fractions.  In order to use the fraction rules, you have to be able to add, subtract, and multiply ordinary whole numbers.  You’ll also want to keep in mind two rules about arithmetic which are very helpful with fractions.

Arithmetic Rule #1

Any number stays the same when zero is added to it or subtracted from it.

3 = 3 + 0 = 3 - 0

Arithmetic Rule #2

Any number stays the same when multiplied or divided by one.

5 = 5 \times 1 = 5 \div 1

Fractions have a few specific terms which are important to know as well.  Here are the big ones:


  • numerator: the number on the top of a fraction
  • denominator: the number on the bottom of a fraction
  • improper fraction: a fraction with a larger numerator than denominator
  • reduced fraction: a fraction that cannot be equivalently written with smaller numerator and denominator
  • mixed fraction: a fraction with a whole number part and a fractional part

On to the rules, of which there are six, but only the last two are particularly interesting.

Fraction Rule #1

Any fraction with 0 as the denominator is undefined (illogical, nonsense, error).


Fraction Rule #2

Any fraction with the same number for both numerator and denominator is equal to 1.

1 = \frac{1}{1} = \frac{8}{8} = \frac{12345}{12345}

Fraction Rule #3

Any fraction with 0 as the numerator is equal to 0 (unless the denominator is also 0 - see rule #1).


Fraction Rule #4

Any simple number can be converted to a fraction by placing it over 1.

2 = \frac{2}{1}

This is the same as the division version of arithmetic rule #2, since fractions are just division problems.

Fraction Rule #5

Fractions with the same denominator are added by adding their numerators and copying the denominator. Fractions with different denominators cannot be added together directly (see below).


Fraction Rule #6

Fractions can be multiplied by multiplying the numerators and denominators separately.


Using the Rules


Division is often a useful thing to do with fractions, and it’s easy.  Just turn the divisor fraction (the second one) upside-down and multiply.  This is commonly referred to as “invert and multiply”.


Improper Fractions

Improper fractions can be made proper by repeatedly pulling 1 (expressed as a fraction) out of the fraction to create a proper mixed fraction.  Remember that every fraction has a “ones” place to the left of the actual fraction to make it a mixed fraction.


The 1 that we want to pull out when converting an improper fraction to proper form is based on the denominator.  By addition rule #1, we can subtract 0 from something without changing it.  And we know that a fraction with the same numerator and denominator is equal to 1 by fraction rule #2.  So if we subtract a one-equivalent fraction and then add 1 back to it, it won’t have changed.


In this case we still have an improper fraction, so we’ll repeat the process again (and continue until we no longer have an improper fraction).


So the improper fraction \frac{5}{2} reduces to the proper mixed fraction 2\frac{1}{2}.

Mixed Fractions

Sometimes you have a mixed fraction and want to make it a pure improper fraction.  Get rid of that pesky whole number part.  Improper fractions are usually easier to manipulate than mixed fractions, so it’s common to make everything improper, solve the problem, and then make the answer proper again.

The process of converting a mixed fraction to an improper fraction is quite simple.  Remember that a mixed fraction is the same as the fractional part plus the whole number part.

2\frac{1}{2}=2 + \frac{1}{2}

If the whole number is converted to a fraction, we can just add them and get a fractional result.  We know how to do that because rule #4 says we can slap a 1 under any whole number.  The denominators won’t match, but arithmetic rule #2 says we can multiply by 1 (a special form – namely the denominator over it self – see rule #2) without affecting anything.

2 + \frac{1}{2}=2\times1 + \frac{1}{2}=\frac{2}{1}\times\frac{2}{2}+\frac{1}{2}=\frac{2\times2}{1\times2}+\frac{1}{2}=\frac{4}{2}+\frac{1}{2}=\frac{5}{2}

This process is a special case of adding fractions with different denominators discussed next.

Adding Fractions With Different Denominators

Adding fractions with different denominators requires multiplying one or both fractions by a special form of 1 first (which doesn’t change anything – see arithmetic rule #2). The trick is in picking the right version of 1 to use.  The goal is to get both fractions to have the same denominator.  The easiest way is to multiply each fraction by the denominator of the other fraction over itself (which is a way of writing 1 – see fraction rule #2).  For the problem


we want to do this


Doing multiplication according to rule #6 yields this


Now that the denominators match (and they always will by following this process) we can add according to rule #5 without difficulty.

\frac{2}{6}+\frac{3}{6}=\frac{2 + 3}{6}=\frac{5}{6}

An there we go, adding two fractions with different denominators by multiplying the parts by a clever form of 1.


Reducing Fractions (Part 1)

Answers to problems, whether in math class or the real world, should almost always be given in reduced fractions.  No one likes to be told \frac{5}{10} when they ask how much pizza is left.  Much better is \frac{1}{2}, but how to get from one to the other?

Since you know that the above rules describe everything you’ll need to do with fractions, it’s probably not surprising that a special form of 1 is integral to the answer. Finding the right form is tricker than for addition above, but there is still a foolproof process.

The first step is to find a non-trivial common factor for the numerator and denominator.  A factor is a number that can be multiplied by another number to get the answer.  For example, 2 and 3 are two factors of 12.  The “non-trivial” means “not including one” since that’s a factor of every number and per addition rule #2 and fraction rule #4 dividing by 1 doesn’t change anything.  We don’t want just any non-trivial factor, however, we need one that is a factor of both the numerator and the denominator (a common factor).

factors of  5: 1, 5
factors of 10: 1, 2, 5, 10

Since 5 is prime, the only options are 1 and itself.  10 has a couple more options, but the only non-trivial common factor of both numerator and denominator is 5.  If you’re reducing a fraction and there are multiple choices for common factors, always pick the largest one.  If you don’t pick the largest one, when you’re done, you only have a partially reduced fraction, not a fully reduced one (and you’ll have to do the process again).  If there aren’t any non-trivial common factors, meaning 1 is the only common factor, then the fraction is already in it’s reduced form.

Now that we have 5 as our factor, we can rewrite our problem by “pulling out” that factor according to rule #6:


Thus we know that \frac{1}{2} is a reduced version of \frac{5}{10}.  Further, since 5 was the largest common factor, we know that it cannot be reduced any further.

Reducing Fractions (Part 2)

A quick way of describing the above process is to say “divide the same number out of top and bottom and repeat you can’t do it anymore”.  It’s still the same process, but mashing a few steps together and not worrying so much about doing it all in one pass.  As an example, reduce \frac{18}{24}.  Top and bottom are both even, so let’s divide out 2.


Still not reduced, but 3 will divide out of each.


Alright, no other numbers can be divided out, so it must be reduced.  If we’d picked 6 (2\times3=6) initially, we’d have been done in one step, because 6 is the largest common factor of 18 and 24 as discussed above.  Doing it this way meant we had to go through the process a couple times, but we didn’t have to figure out the list of factors and then figure out the largest common factor.

Both approaches are 100% correct and will yield the same result every time.  If you’re doing the reduction in your head while baking, chances are you’ll do the quick’n'dirty way.  If you’re doing the reduction while designing a bridge strut, you’ll probably do it the longer way.  Regardless which you choose, the answer will be the same.

Reducing Proper and Improper Fractions

Reducing fractions and switching from proper and improper forms are all simple conversions.  They’re not changing the fraction’s value, just the way it’s written.  Thus if you have to do both, it’s completely irrelevant which order you do them.

Since a proper fraction’s whole number part is always reduced (whole numbers are as reduced as they come), doing the reduction second is often easier because the numbers in the fraction will be smaller.  But it doesn’t change the math at all; the result is the same.

Groovy’s Collection.minus(Collection)

If you’ve done much Groovy development, you’ve probably used all the handy helper methods that it provides to augment the core JRE classes.  Collections, in particular, have some really helpful additions in the form of operator extension.  For example, the minus operator works like this:

assert [1, "a", true, true, false, 5.3] - [true, 5.3] == [1, "a", false]

This is all sorts of handy, but I found an interesting bug in Groovy 1.8.4′s implementation.  Behind the scenes, it uses two different Comparators to do the equality checks needed to perform the subtraction.  However, the Comparators are a little off…

The first Comparator is actually just the DefaultTypeTransformation.compareTo method, and it gracefully handles non-Comparable, non-equal objects with the same hashCode.  It also handles nulls (which are always first), and a bunch of standard type conversions (e.g., char -> String when compared to a String).

The second Comparator, however, it less well behaved.  It’s called NumberAwareComparator, and delegates to DefaultTypeTransformation.compareTo first.  But if that fails, it falls back to a hashCode comparison, which creates a very interesting bug: if two non-equal objects have the same hashCode, NumberAwareComparator will return zero from it’s compareTo method, which will be interpreted as equality in a variety of contexts.

The workaround that I’ve found is to explicitly implement Comparable in the domain model at the appropriate level(s) so that you always have a mutually-comparable collection, and you can implement compareTo in a way consistent with equals.  Implementing Comparable like this will ensure that DefaultTypeTransformation.compareTo will successfully handle the comparison, thus preventing falling through to NumberAwareComparator.

Sometimes, it is the library.  : )

Domino Functions

At Gram and Gramp’s this weekend we played dominos, and the question came up of counting a set of dominos.  In particular, Gramps wanted to know how many dominos there were in a set with double twelves.

After we were done playing, we lined them all up in the “domino triangle” with and Emery and I figured it out.    The domino triangle is simply an arrangement of dominos with double zero in one corner, the zero-one next to it, followed by zero-two (etc.), and with the double one at the end, followed by the double two (etc.).  Here is a partial rendering of the triangle for our double nine set:

+-+   +-+         +-+
|0|   |0|         |0|
+-+   +-+   ...   +-+
|0|   |1|         |9|
+-+   +-+         +-+

+-+         +-+
|1|         |1|
+-+   ...   +-+
|1|         |9|
+-+         +-+



To start, let n equal the number of the largest double (twelve, if our case).  We’re looking for f(n), which is the number of dominos in a set with largest double n.  Simply counting the dominos in the triangle gives us a values for our function, but not the one we want:

  n  | f(n)
  0  |   1
  6  |  28
  9  |  55
 12  |  ??

Before dealing with f(n), let g(n) denote the number of doubles in the set.  A quick glance at the triangle will show that the formula for this function is


because there is one double for each

[0, n] = \{x \in \mathbb{N} \,|\,0 \le x \le n\}

Now thinking back to the “domino triangle”, it’s easy to see that g(n) is both the width (base) and the height of the triangle.  If you recall from planar geometry, the area of a triangle is half it’s base times height:

\frac{base \times height}{2}

So a first guess at f(n) would be this:


But that isn’t correct.  Thinking back to the domino triangle quickly shows why.  If you were to take two copies of the triangle to make a rectangle (the reason the triangle area formula works), you’d see that you’d have to offset them by one domino in one direction, so the rectangle is actually g(n) by g(n) + 1.  So the right formula is this:

f(n)=\frac{g(n)\,(g(n) + 1)}{2}

Simplifying by inlining the formula for g(n) yields:

f(n)=\frac{(n + 1)(n + 2)}{2}

This turns out to be the correct formula, and yields 91 when its argument is twelve.  Thus a set of double twelve dominos will have 91 dominos.

What was particularly striking as Emery and I worked through the formulas, is that Emery had more trouble with the larger multiplication (which he hasn’t done in school) than following the function notation, doing the step-wise evaluation of the functions, and even the function nesting.

Branching and Refactoring

Mark Mandel made an interesting post about branching strategies when you have both feature development and refactoring to perform together.  Specifically, he’s wondering how best to ensure you don’t orphan the refactoring if you abandon the feature, since the refactoring might be useful elsewhere.

I posted my comments, and you should too.  Effectively using your tools is vital to success in the software world, and no tool has more potential value (and potential pitfalls) than source control.

Everything you care about having around tomorrow should be stored in source control.  That obviously means your source code, but also includes your build/deploy scripts, editor/IDE config files, design documents, etc.

Hql For Groovier Hibernate

If you’ve done much with Groovy, you probably know about the slick Sql class that it provides for interfacing with a SQL datastore across JDBC. It’s not perfect, but it’s certainly easy.  I was working on a Hibernate project and wanted the same thing for my HQL queries, so I threw together a simple Hql class to provide the same sort of behaviour.

Like Sql, it can be parameterized with a connection source (a SessionFactory in this case) or a specific connection (a Session).  If given a SessionFactory, it’ll use getCurrentSession() to grab a Session when one is needed, which allows you to wire a single Hql instance up in your Spring config, supply it your SessionFactory, and then inject the Hql into all your persistence-aware beans and just use it.

It also provides a public getSession() method for returning the current session to those same beans, which means you can just inject the Hql instance and not have to also inject the SessionFactory instance if you’re feeling lazy (or doing some quick prototyping).  I will leave whether that’s an appropriate long-term approach for a different discussion.

Here she be:

import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;

 * I aim to be sort of like Groovy's builtin Sql class, except for Hql
 * @author
class Hql {

  private Session __sess
  private SessionFactory __sf

  def Hql(SessionFactory sf) {
    __sf = sf

  def Hql(Session s) {
    __sess = s

  SessionFactory getSessionFactory() {

  Session getSession() {
    __sess ?: __sf.currentSession

  Object unique(String hql, List params=null) {
    new Statement(hql, params).query(session).uniqueResult()

  Object unique(GString gstring) {
    new Statement(gstring).query(session).uniqueResult()

  List list(String hql, List params=[], Integer firstResult=null, Integer maxResults=null) {
    new Statement(hql, params, firstResult, maxResults).query(session).list()

  List list(GString gstring, Integer firstResult=null, Integer maxResults=null) {
    new Statement(gstring, firstResult, maxResults).query(session).list()

  private class Statement {
    String hql
    List params
    Integer firstResult
    Integer maxResults

    def Statement(String hql, List params, Integer firstResult=null, Integer maxResults=null) {
      this.hql = hql
      this.params = params ?: []
      this.firstResult = firstResult
      this.maxResults = maxResults

    def Statement(GString gstring, Integer firstResult=null, Integer maxResults=null) {
      def hql = new StringBuilder()
      def params = []
      def prefix
      gstring.strings.eachWithIndex { str, i ->
        if (i > 0) {
          def v = gstring.getValue(i - 1)
          if (v != null) {
            params += v
          } else {
            if (prefix.trim().endsWith('=')) {
              prefix = prefix.replaceFirst(/=(\s*)$/, ' is$1')
        prefix = str
      hql = hql.toString()
      this.hql = hql
      this.params = params
      this.firstResult = firstResult
      this.maxResults = maxResults

    Query query(Session sess) {
      def q = sess.createQuery(hql)
      params.eachWithIndex { o, i ->
        q.setParameter(i, o)
      if (firstResult != null) {
        q.firstResult = firstResult
      if (maxResults != null) {
        q.maxResults = maxResults

I am a Programmer Luddite

Several years ago I decided that I didn’t want to use the ‘‘ domain for my personal blog anymore.  I’m not sure what the catalyst was, or even whether there was a catalyst, but I do know that there were two primary factors at play.  Those factors have remained constant (if not increasing in relevance) over the intervening years, and I am now happy to say I have a new blog here at  And yes, will also work for those of you who, like me, can never get the words in the right order.

The first factor was the morass that had become.  It has housed between seven and twelve WordPress blogs, several large-scape web apps, a pile of little utilities and demo apps for various purposes, all of my self-contained open source projects, and eight years worth of blog posts.  The domain has lived on an old Dell laptop, an old workstation in my basement, a massively shared PHP host, a dedicated server, and now on EC2.  This has yielded a URL structure which is somewhat convoluted and an Apache HTTPD configuration which was even more insane.

The second factor was that the history of BarneyBlog (my blog at indicated a trajectory which didn’t really match real life.  I don’t think it accurately reflects the developer that I am, let alone the person I am.  Which isn’t to say that it doesn’t represent reality, of course.  At the micro level, each individual post is a valid glimpse into my world, but the whole doesn’t seem to match up at the macro level.

The net of it was that I wanted a new projection of myself onto the web.

About the same time I realized just how little affinity I have for technology in general.  Technology is a tool, and while it can be a useful tool, no tool can hope to exist for it’s own sake.  Tools “buy” their existence through utility; non-useful tools aren’t tools, they’re just stuff.  A huge swath of technology falls into this latter category, and I seem to be fairly unique amongst my peers in judging such tech purely on utility.  The “luddite” moniker is not a perfect fit, but it certainly conjures up the appropriate imagery.

The other half of the name was somewhat more difficult to pin down.  I’ve spent a lot of time over the past five or seven years thinking about what label best describes what I do in my chosen career.  None of them seem to match up perfectly.  I’ve adopted the term “software craftsman”, but calling this site “software craftsman luddite” seemed rather pretentious.  “Programmer”, I think, indicates a similar love of the act of programming.  I.e., the love of programming itself, not the creation of software (which necessarily has an external purpose).  Yes, I appreciate the irony.

I write code to fulfill needs.  I create tools, some for me and some for others.  But my love of software development is selfish.  Meeting people’s needs with software is pleasing; crafting beautiful software is satisfying.  I solve problems with technology.  I eschew technology for it’s own sake.  I am a programmer luddite.