by Johnny Winn on January 23, 2013

The new year is in full swing with February approaching fast and bringing with it the much anticipated release of Ruby 2.0. So it seems like the perfect time to explore a couple of its new features. Two that I found interesting were the Enumerator::Lazy and Refinements so today we'll look at implementing a solution to a Project Euler challenge. This implementation will allow us to utilize these two features without a contrived example. After all, the Ruby 2.0 features are the focus.

For those new to Project Euler, it's a site that offers a series of mathematical, or computer programming, challenges to sharpen your problem solving skills. The challenges range in difficulty but since our focus is the language features the problem isn't as important as the solution. Our challenge is to find the sum of all multiples of 3 and 5 below 1000. Since we are looking for an answer before we begin our implementation, it's safe to spike using existing Ruby functionality.

(1..1000).select { |i| i % 3 == 0 || i % 5 == 0 }.reduce(:+)
=> 234168

After verifying that the answer is correct on the Project Euler site, we can write a test and start exploring the new features. Our test will provide a fall back as we make our changes.

describe "Ruby 2.0 features" do
  context "Multiples of 3 and 5" do
    it "Sum of all the multiples of 3 or 5 below 1000" do
      FunctionalRuby.sum_multiples_of_3_and_5_for_range((1..1000)).should eq(234168)
    end
  end
end

This is arguably a bit verbose and of course the test fails, however, it's a good starting point so we can begin.

The first Ruby 2.0 feature we will implement is Enumerator::Lazy but before we do, let's look back at our original spike.

(1..1000).select { |i| i % 3 == 0 || i % 5 == 0 }.reduce(:+)
=> 234168

At first glance this code seems harmless enough and many of us have probably implemented a similar solution. However, this code can be misleading because Ruby creates a complete array prior to executing the reduce(:+) function. This proves particularly sticky when subsequent calls pull only a subset of data from the original array. The entire array must be built before retrieving the subset. Take a look at this example.

(1..Float::INFINITY).select { |x| x % 3 == 0 || x % 5 == 0}.take(5).reduce(:+)

Because the array must be completely built prior to calling take(5) and it's an infinite set, the additional methods are never called.

A common idiom in functional programming is lazy evaluation. Lazy evaluation delays the functions execution until its value is needed. Ruby 2.0 introduces lazy evaluation through Enumerator::Lazy. This addition can solve our infinity problem by delaying the execution of the iteration.

(1..Float::INFINITY).lazy.select { |x| x % 3 == 0 || x % 5 == 0}.take(5).reduce(:+)
=> 33

So our next step is to implement a solution for our challenge using Enumerator::Lazy feature.

class FunctionalRuby

  def self.sum_multiples_of_3_and_5_for_range(range)
    range.lazy.select { |i| i % 3 == 0 || i % 5 == 0 }.reduce(:+)
  end

end

When we run our tests, everything passes and all is well, kinda.

Although we are moving in the right direction, our method doesn't really reflect a functional programming style. First, we have a single function with multiple responsibilities. Second, if we could curry the method calls it would provide a solution that is easier to read. Prior to Ruby 2.0 one might suggest monkey patching the Enumerator::Lazy module to add methods in order to chain them to lazy. But we don't want our methods to pollute the Ruby module in every instance because these methods are specific to our solution. Ruby 2.0 offers a solution in the Refinements feature.

The Refinement feature is dependent on two methods: Module#refine and using. We can start our refactoring by adding a custom module and refining the Enumerator::Lazy module. Because it's unique to our Project Euler challenge we will name it accordingly.

module ProjectEuler
  refine Enumerator::Lazy do

    def multiple_of_3(number)
      number % 3 == 0
    end

    def multiple_of_5(number)
      number % 5 == 0
    end

    def select_multiples_of_3_and_5
      select { |x| multiple_of_3(x) || multiple_of_5(x) }
    end

    def then_sum
      reduce(:+)
    end
  end
end

class FunctionalRuby
  using ProjectEuler

  def self.sum_multiples_of_3_and_5_for_range(range)
    range.lazy.select_multiples_of_3_and_5.then_sum
  end

end

A quick run of the test to verify we are still passing and we can start to look at what's happening in the solution. The ProjectEuler module has defined a refinement for the Enumerator::Lazy module and added the additional methods. Any class that applies the ProjectEuler module through a using method can take advantage of the monkey patch. This also includes overriding existing methods. We can DRY this code up by overriding the method_missing call and consolidating the multiple_of_ methods.

module ProjectEuler
  refine Enumerator::Lazy do

    def method_missing(method, *args, &block)
      if method.to_s =~ /multiple_of_(.*)$/
        multiple_of($1.to_i, args[0].to_i)
      end
    end

    def multiple_of(multiple, number)
      number % multiple == 0
    end

    def select_multiples_of_3_and_5
      select { |x| multiple_of_3(x) || multiple_of_5(x) }
    end

    def then_sum
      reduce(:+)
    end
  end
end

Now this may be taking things to the extreme for this scenario but the purpose is to demonstrate that the method_missing call can be overridden in this refinement without affecting the original module. We can test this by calling our custom method without applying the using statement to a class

class WithoutEuler
  def self.call_multiple_of_3_on_lazy
    (1..5).lazy.select_multiples_of_3_and_5
  end
end


WithoutEuler.call_multiple_of_3_on_lazy
=> NoMethodError: undefined method `select_multiples_of_3_and_5' for #<Enumerator::Lazy: 1..1000>

It's clear that these examples are more academic then real-world but they provide an opportunity to review specific language features rather than focusing on the solution details. Ruby is a procedural language, but it can be fun to apply functional idioms to explore its nuances. These two features seemed like an excellent starting point for this type of experimentation. The Ruby 2.0 release has several more interesting features and we will be exploring many of them through similar experiments and reporting back our findings. Until then, happy hacking!