Sam Davis

sed ‘/^\s*$/d’ Hakyll.Template

2016-08-16T00:00:00+01:00

Hakyll is a Haskell library for generating static sites, mostly aimed at small-to-medium sites and personal blogs. It is written in a very configurable way and uses an xmonad-like DSL for configuration.

At ZuriHac this year I created a patch for Hakyll’s issue #414 - “$for template leaves trailing spaces behind”. The change enables users to purge the redundant whitespace, created when using Hakyll’s markup language, from any of the files generated with the templating system!

This post starts by giving a brief overview of Hakyll and it’s templating system and markup language before introducing issue #414 that, from this point on, will be referred to as The Whitespace Problem. It finishes by exploring the features provided by other popular templating engines, such as Python’s jinja2.

Templates and Markup!

Approach #1

An animal rehoming centre wishes to create a website to advertise each animal requiring a home. They have three so, in order to keep things simple, they create a static site consisting of three pages, one per animal. Each page has a header that links to every other page.

Foo’s page - foo.html:

<html>
<head>
  <title>Foo the Ferret</title>
</head>
<body>
  <a href="./foo.html">Foo</a>
  <a href="./bar.html">Bar</a>
  <a href="./baz.html">Baz</a>
  <h1>Foo the Ferret</h1>
  <img src="foo.jpg">
  <p>
    Foo's amazing.
  </p>
</body>
<footer>
  <a href="mailto:rehoming@example.com">Contact us!</a>
</footer>
</html>

This approach breaks down as the number of animals grows - O(n) edits are required upon the nth animal entering the centre (at least the header on every page needs updating) meaning O(n!) edits in total over the website’s lifetime! This approach also makes updating common code, such as the contact details or site layout, difficult and error-prone due to the sheer number of duplicated changes across every page.

The solution? Templates and markup!

Approach #2

Templates enable common code to be broken out into separate files, reducing WETness, and markup provides a simple metaprogramming language to both tie together the individual templates and content and to generate additional code in the templates at compile time, increasing DRYness!

A template for the above example - template.html:

<html>
<head>
  <title>$title$</title>
</head>
<body>
  $for(animals)$
    <a href="$url$">$title$</a>
  $endfor$

  <h1>$title$</h1>

  $if(img)$
    <img src="$img$">
  $endif$

  $body$
</body>
<footer>
  <a href="mailto:rehoming@example.com">Contact us!</a>
</footer>
</html>

The markup consists of expressions and statements, resembling a simple C-world language, that render to strings at compile time. The value of any variables, such as title, are determined by indexing a context which can be thought of as a map. More information about their use and implementation is available on the Hackage Hakyll.Web.Template page.

The complete site.hs Hakyll file using the above:

data Animal = Animal{ title      :: String
                    , identifier :: Identifier
                    , content    :: String
                    , img        :: Maybe String
                    }

animals = [ Animal{ title      = "Foo the Ferret"
                  , identifier = "foo.html"
                  , content    = "<p>\nFoo's amazing!\n</p>"
                  , img        = Just "foo.jpg"
                  }
          , Animal{ title      = "Bar the Bison"
                  , identifier = "bar.html"
                  , content    = "<p>\nBar's awesome!\n</p>"
                  , img        = Nothing
                  }
          ]

main :: IO ()
main = hakyll $ do
  match "template.html" $
    compile templateCompiler

  match "*.jpg" $ do
    route   idRoute
    compile copyFileCompiler

  create (map identifier animals) $ do
    route idRoute
    compile $ do
      ident <- getUnderlying
      let animal = fromJust $ find ((== ident) . identifier) animals
          animalCtx = constField "title" (title animal)
                   <> urlField "url"
                   <> constField "content" (content animal)
                   <> maybe mempty (constField "img") (img animal)
                   <> listField "animals" animalsCtx (mapM makeItem animals)

          animalsCtx = field "title" (pure . title . itemBody)
                    <> field "url"   (pure . toFilePath . identifier . itemBody)

      makeItem "" >>= loadAndApplyTemplate "template.html" animalCtx

Each animal’s information is contained within an instantiation of the Animal data constructor and updating the animals :: [Animal] list updates the entire site! This solution causes the total number of edits to drop to O(n) but it still has an issue when scaling: the length of the site.hs file increases linearly with the number of animals. Hakyll’s metadata feature, combined with templating, could be used solve this problem by splitting the list out into separate files but this is beyond the scope of this post.

The Whitespace Problem

With the above in place, visiting /foo.html shows:

<html>
<head>
  <title>Foo the Ferret</title>
</head>
<body>

    <a href="foo.html">Foo the Ferret</a>

    <a href="bar.html">Bar the Bison</a>


  <h1>Foo the Ferret</h1>


    <img src="foo.jpg">


  <p>
Foo's amazing!
</p>
</body>
<footer>
  <a href="mailto:rehoming@example.com">Contact us!</a>
</footer>
</html>

The above code has strange indenting and seems to contain excess line feeds - these problems combine to form The Whitespace Problem!

Why?

Hakyll parses templates using the following context-free grammar (EBNF) (Note: Some productions seem redundant but it’s how it’s defined in the code so they have been left in order to aid in mapping between the two):

template = { chunk | escaped | conditional | for | partial | expr } ;

chunk = noDollar , { noDollar } ;

noDollar = ? Data.Char.Char - "$" ?

escaped = "$$"

conditional = "$if(" , expr_ , ")$" , template , [ "$else$", template ] , "$endif$" ;

for = "$for(" , expr_ , ")$" , template , [ "$sep$" , template ] , "$endfor$" ;

partial = "$partial(" , expr_ , ")$" ;

expr = "$" , expr_ , "$" ;

expr_ = stringLiteral | call | ident ;

stringLiteral = '"' , { noSlash , slash } , '"' ;

noSlash = ? noQuote - '\' ? ;

slash = '\' , noQuote ;

noQuote = ? Data.Char.Char - '"' ? ;

call = key , "(" , { spaces } , args , { spaces } , ")" ;

ident = key ;

key = metadataKey ;

spaces = ? Data.Char.isSpace ? ;

args = { expr_ , { spaces , "," , spaces , expr_ } } ;

metadataKey = ( letter , { alphaNum | "_" | "-" | "." } ) - reservedKeys ;

letter = ? Data.Char.isAlpha ? ;

alphaNum = ? Data.Char.isAlphaNum ? ;

reservedKeys = "if" | "else" | "endif" | "for" | "sep" | "endfor" | "partial" ;

to create an abstract syntax tree (AST) represented by the following recursive algebraic data type (ADT):

newtype Template = Template [TemplateElement]

-- | Elements of a template.
data TemplateElement
    = Chunk String
    | Expr TemplateExpr
    | Escaped
    | If TemplateExpr Template (Maybe Template)   -- expr, then, else
    | For TemplateExpr Template (Maybe Template)  -- expr, body, separator
    | Partial TemplateExpr                        -- filename

newtype TemplateKey = TemplateKey String

-- | Expression in a template
data TemplateExpr
    = Ident TemplateKey
    | Call TemplateKey [TemplateExpr]
    | StringLiteral String

A Template is a list of TemplateElements. A TemplateElement is either markup code that is signified by “$” bookends, or a chunk of text which could be anything. i.e. plaintext, HTML, Haskell, Python etc.

The latter is captured by the Chunk constructor. The former can be an:

Expr: A variable or function call (must be defined in used Context)
- $ident$
- $func("arg")$
Escaped: A literal ‘$’ rather than signifying markup.
- Only $$2.99!
If: If statement with optional else clause.
- $if(variable)$ foo $endif$
- $if(variable)$ foo $else$ bar $endif$
For: For statement with optional separator string.
- $for(things)$ $thing$ $endfor$
- $for(things)$ $thing$$sep$, $endfor$
Partial: “Loads a template located in a separate file and interpolates it under the current context.”
- $partial("path.html")$

The Whitespace Problem occurs because any whitespace preceding or trailing a markup element is captured in a Chunk and is thus untouched when that element is rendered as a string. Note that it is untouched because Hakyll mapMs applyElem :: TemplateElement -> Compiler String over each TemplateElement, as can be seen here, and thus each application has no knowledge of any surrounding TemplateElements.

An example:

template.tpl file:

<body>
  $if(var)$
    $var$
  $endif$
</body>

Loading as a Template:

> import Hakyll.Web.Template.Internal
> readTemplate <$> readFile "template.tpl"
Template [Chunk "<body>\n  ",If var (Template [Chunk "\n    ",Expr var,Chunk "\n  "]) Nothing,Chunk "\n</body>\n"]

Pretty printed [TemplateElement]’s:

Template [ Chunk "<body>\n  "
         , If var
              (Template [ Chunk "\n    "
                        , Expr var
                        , Chunk "\n  "
                        ])
              Nothing
         , Chunk "\n</body>\n"
         ]

Rendering with:

ctx :: Context String
ctx = constField "var" "foo"

Yields:

<body>

    foo

</body>

in Haskell:

> readFile "_site/template.html"
"<body>\n  \n    foo\n  \n</body>\n"

Solution?

The solutions for The Whitespace Problem in the other templating systems seem to consist of two parts:

Syntactic: Augment the markup language to enable the removal of whitespace.
Semantic: Augment the module(s) to handle any language change(s).

The implementation of each part in both jinja2, “a modern and designer-friendly templating language for Python”, and ERB, an implementation of eRuby which is a templating system that permits Ruby code to be embedded in a file, is discussed below.

State Comparison

Jinja2 - Syntactic

As per the documentation, Jinja’s default delimiters (bookends) are:

{% ... %} for Statements

{{ ... }} for Expressions to print to the template output

However, unlike Hakyll, Jinja is configured such that “An application developer can change the syntax configuration from {% foo %} > to <% foo %>, or something similar.”

Jinja’s documentation on whitespace control explains it’s syntactic part. This is quoted verbatim to preserve it in this post:

…

If an application configures Jinja to trim_blocks, the first newline after a template tag is removed automatically (like in PHP). The lstrip_blocks option can also be set to strip tabs and spaces from the beginning of a line to the start of a block. (Nothing will be stripped if there are other characters before the start of the block.)

With both trim_blocks and lstrip_blocks enabled, you can put block tags on their own lines, and the entire block line will be removed when rendered, preserving the whitespace of the contents. For example, without the trim_blocks and lstrip_blocks options, this template:
<div>
    {% if True %}
        yay
    {% endif %}
</div>
gets rendered with blank lines inside the div:
<div>

        yay

</div>
But with both trim_blocks and lstrip_blocks enabled, the template block lines are removed and other whitespace is preserved:
<div>
        yay
</div>
You can manually disable the lstrip_blocks behavior by putting a plus sign (+) at the start of a block:
<div>
        {%+ if something %}yay{% endif %}
</div>
You can also strip whitespace in templates by hand. If you add a minus sign (-) to the start or end of a block (e.g. a For tag), a comment, or a variable expression, the whitespace before or after that block will be removed:
{% for item in seq -%}
    {{ item }}
{%- endfor %}
This will yield all elements without whitespace between them. If seq was a list of numbers from 1 to 9, the output would be 123456789.

…

Note:

You must not add whitespace between the tag and the minus sign.

valid:
{%- if foo -%}...{% endif %}
invalid:
{% - if foo - %}...{% endif %}

The above, in short, is that Jinja has both a global and local method of trimming whitespace. The global method is enabled via two flags, trim_blocks and lstrip_blocks, and can be locally disabled with a ‘+’, e.g. +%}. The local method is enabled with a ‘-‘, e.g. -%}.

Jinja2 - Semantic

Jinja passes an Environment around the compilation process that “contains important shared variables like configuration, filters, tests, globals and others.”. Both trim_blocks and lstrip_blocks are Environment variables. The state of the given Environment changes the behaviour of the compilation phases and causes whitespace to be trimmed in the Lexer.

>>> import jinja2
>>> from jinja2.environment import Environment
>>> from jinja2.lexer import Lexer
>>> s = '''    {% if True %}\n    foo\n    {% endif %}'''
>>> env = Environment(lstrip_blocks=False, trim_blocks=False)
>>> list(Lexer(env).tokenize(s))
[Token(1, 'data', u'    '), Token(1, 'block_begin', u'{%'), Token(1, 'name', 'if'), Token(1, 'name', 'True'), Token(1, 'block_end', u'%}'), Token(1, 'data', u'\n    foo\n    '), Token(3, 'block_begin', u'{%'), Token(3, 'name', 'endif'), Token(3, 'block_end', u'%}')]
>>> env = Environment(lstrip_blocks=True, trim_blocks=True)
>>> list(Lexer(env).tokenize(s))
[Token(1, 'block_begin', u'    {%'), Token(1, 'name', 'if'), Token(1, 'name', 'True'), Token(1, 'block_end', u'%}\n'), Token(2, 'data', u'    foo\n'), Token(3, 'block_begin', u'    {%'), Token(3, 'name', 'endif'), Token(3, 'block_end', u'%}')]

ERB - Syntactic

ERB’s delimiters are:

<% ... %> for Statements (scriptlets)
<%= ... %> for Expressions

A template is rendered by passing it as an argument to the ERB object’s constructor and then calling the result method. e.g:

require 'erb'

foo = "bar"
tpl = "<%= foo %>"

render = ERB.new(tpl)
puts render.result()

Outputs:

bar

Whitespace is controlled by the trim_mode argument to the new method. This is documented here. Again, the relevant part has been quoted directly in order to preserve it for the context of this post.

If trim_mode is passed a String containing one or more of the following modifiers, ERB will adjust its code generation as listed:
%  enables Ruby code processing for lines beginning with %
<> omit newline for lines starting with <% and ending in %>
>  omit newline for lines ending in %>
-  omit blank lines ending in -%>

ERB’s syntactic part is similar to Jinja’s syntactic part in several ways:

It has global and local whitespace trimming.
Trimming is enabled via flags.
Local trimming is enabled with a ‘-‘, e.g. -%>

ERB - Semantic

Ruby has an ERB class that “Compiles ERB templates into Ruby code; the compiled code produces the template result when evaluated”.

Example use:

+irb(main):001:0> require 'erb'
=> true
+irb(main):002:0> compiler = ERB::Compiler.new('<>')
=> #<ERB::Compiler:0x000000009c0d88 @percent=false, @trim_mode="<>", @put_cmd="print", @insert_cmd="print", @pre_cmd=[], @post_cmd=[]>
+irb(main):003:0> code, enc = compiler.compile("Template <%= obj %>!\n")
=> ["#coding:UTF-8\nprint \"Template \"; print(( obj ).to_s); print \"!\\n\"\n", #<Encoding:UTF-8>]
+irb(main):004:0> obj = "Foo"
=> "Foo"
+irb(main):005:0> eval code
Template Foo!
=> nil

The ERB class contains a series of nested classes:

class ERB
  class Compiler

    ...

    class Scanner
      ...
    end

    class TrimScanner < Scanner
      ...
    end

    class SimpleScanner < Scanner
      ...
    end

    ...

  end
end

The new method called to instantiate an ERB::Compiler takes a trim_mode as an argument and uses it to select a Scanner. A Scanner is, essentially, a lexer and thus ERB also removes whitespace during the lexical analysis phase.

Sudoku Solving

2015-07-23T00:00:00+01:00

Sudoku is an nxn grid based puzzle, typically 9x9, in which the aim is to fill each of the cells with an element from the set (1..n) such that the rows, columns and, in the examples beneath 3x3, sub-grids contain all elements from (1..n). Some of the cells of a puzzle are filled in, these are known as the givens.

There are many different algorithms with varying complexities that can be used to solve a Sudoku but brute force, backtracking, and Dancing Links are discussed, implemented in Ruby, and benchmarked below.

Example Sudoku:

Sudoku Model

The aim, using the strategy pattern, is to produce a family of algorithms that can be interchangeably used to solve a Sudoku. Each algorithm will model a Sudoku puzzle as a single string made from the concatenation of its rows with ‘.’ representing the unknown cells. Thus the example above becomes:

".3..........195....98....6.8...6....4....3..1....2.....6....28....419..5.......7."

and the unique valid solution:

"534678912672195348198342567859761423426853791713924856961537284287419635345286179"

This data structure is encompassed by the Sudoku class. The class provides methods that return arrays of the Sudoku’s rows, columns, and sub-grids respectively. These are calculated from the internal string representation upon method call and the results are cached to reduce the access time of future requests. It also overrides ‘to_s’ for pretty printing and provides getter and setter methods, ‘[]’ and ‘[]=’, for accessing and modifying the internal string, ensuring to invalidate any cached values upon change.

The last method is ‘solve’ that, using dynamic dispatch, will use the given algorithm to return a valid solution (provided one exists).

class Sudoku

  def initialize(string)
    @string = string
  end

  def rows
    @rows ||= @string.scan(/.{9}/)
  end

  def columns
    @columns ||= rows.map(&:chars).transpose.map(&:join)
  end

  def sub_grids
    return @sub_grids if @sub_grids

    grid_builder = Hash.new { |h, k| h[k] = Array.new }

    (0...9).each do |i|
      (0...9).each do |j|
        # 3x3 blocks, numbered 0 to 8, run left to right, top down.
        block = (j / 3) + (3 * (i / 3))
        grid_builder[block] << rows[i].chars[j]
      end
    end

    @sub_grids = grid_builder.values.map(&:join)
  end

  def to_s
    @string
  end

  def [](n)
    @string[n]
  end

  def []=(n, v)
    @string[n] = v
    @rows = @columns = @sub_grids = nil
  end

  def solve(algorithm)
    algorithm.solve(self)
  end
end

The first two algorithms, brute force and backtracking, will require a way to check if a possible candidate solution is valid. This can be achieved by implementing methods to test if a candidate meets the three conditions stated above. To keep the code as DRY as possible these will be wrapped in a Solution module and used as a mixin where necessary.

module Solution

  private

  def solution?(candidate)
    valid?(:rows,      candidate) &&
    valid?(:columns,   candidate) &&
    valid?(:sub_grids, candidate)
  end

  def valid?(type, candidate)
    candidate.send(type).all? { |a| a.chars.sort == ("1".."9").to_a }
  end
end

Brute force

A brute force or exhaustive search algorithm aims to find a solution by enumerating through all possible candidates until one passes. There are 6,670,903,752,021,072,936,960 distinct Sudoku puzzles thus this method is not quick however it does guarantee that a solution will be found provided the puzzle is correct!

The ‘solve’ method iterates through each candidate and returns it if it’s a solution. Checking is made easy by including the Solution mixin shown above. Generating candidates is done in a naive way by enumerating through all possible 81 digit numbers from “111…1” to “999…9”, skipping those that include a 0 or contain values that don’t match the puzzle’s givens.

require_relative 'solution'
require_relative 'sudoku'

class BruteForce

  extend Solution

  def self.solve(sudoku)
    candidates(sudoku).find { |candidate| solution? candidate }
  end

  private

  def self.candidates(sudoku)
    return enum_for(:candidates, sudoku) unless block_given?

    ("1"*81.."9"*81).each do |candidate|
      next if candidate.include?("0")
      next unless matching_givens?(candidate, sudoku)
      yield Sudoku.new(candidate)
    end
  end

  def self.matching_givens?(candidate, sudoku)
    # Convert sudoku to regex & match. Works as unknowns are represented by "."
    Regexp.new(sudoku.to_s).match(candidate.to_s)
  end
end

Backtracking

The backtracking algorithm effectively walks left to right along the string representation of a puzzle replacing unknown cells with a value, ensuring to preserve the invariant that each number in the set (1..9) must be unique in each row, column and sub-grid, and returning the solution if found.

The algorithm backtracks if an unknown value cannot be filled or the end of the string is reached without a solution being found. It does so by walking back to the last unknown cell and replacing it with an unused but still correct value. If there are no possible values then the cell is reset to “.” and the backtracking process repeats.

A logged output of the algorithm solving a Sudoku can be found here.

This can also be thought of as a depth-first traversal of a tree of candidate solutions with the tree’s branches and nodes only being created when required thus reducing the typical space and computation requirements.

The walk, or tree traversal, is handled by the recursive method ‘search’. As ‘search’ modifies the given sudoku it must not be invoked directly. Instead the ‘solve’ method first duplicates the given sudoku and then calls ‘search’, this protects the user from any unexpected side effects.

require_relative 'solution'
require_relative 'sudoku'

class Backtracking

  extend Solution

  def self.solve(sudoku)
    # New copy to avoid changing original sudoku.
    temp = Sudoku.new(sudoku.to_s.dup)
    search(0, temp)
  end

  private

  def self.search(n, sudoku)
    return nil if n > 80
    return sudoku if solution?(sudoku)

    # Given cell.
    if sudoku[n] != "."
      return search(n + 1, sudoku)
    end

    # Unknown cell.
    values(n, sudoku).each do |value|
      sudoku[n] = value
      solution = search(n + 1, sudoku)
      return solution if solution
    end

    # Every possible value explored, reset cell, report no solution.
    sudoku[n] = "."
    nil
  end

  def self.values(n, sudoku)
    row, column = n / 9, n % 9
    sub_grid = (column / 3) + (3 * (row / 3))

    ('1'..'9').to_a - sudoku.rows[row].chars \
                    - sudoku.columns[column].chars \
                    - sudoku.sub_grids[sub_grid].chars
  end
end

Dancing Links

Dancing links, also known as DLX, is the technique suggested by Donald Knuth to efficiently implement his Algorithm X. More

“Algorithm X” is the name Donald Knuth used in his paper “Dancing Links” to refer to “the most obvious trial-and-error approach” for finding all solutions to the exact cover problem.

The exact cover problem is represented in Algorithm X using a matrix A consisting of 0s and 1s. The goal is to select a subset of the rows so that the digit 1 appears in each column exactly once. More

The idea of this algorithm is to reduce the problem of solving a Sudoku to that of exact cover. This is achieved by creating a sparse matrix of 0s and 1s that represents a given puzzle, finding a subset of this matrix’s rows such that each column of the combined subset contains exactly one 1, and then transforming these rows back into a solution.

The matrix has four blocks of columns, each 81 bits in length, that correspond to the following constraints:

Each row can only contain each number once.
Each column can only contain each number once.
Each sub-grid can only contain each number once.
Each cell can only contain one number.

Each row in the matrix represents a certain configuration thus there are four bits per row, one for each constraint.

A visual of the matrix showing all the candidate possibilities and constraints can be found here.

The ‘constraints’ method is used to generate the rows, skipping over any that are invalid due to the given values of the puzzle. These rows are added to a sparse matrix from my implementation of Knuth’s dancing links here and the first set of rows that it returns is converted back into a Sudoku and returned as the solution.

require 'dlx/sparse_matrix'
require_relative 'sudoku'

class DancingLinks

  def self.solve(sudoku)
    matrix = Dlx::SparseMatrix.new
    constraints(sudoku).each { |constraint| matrix.add(constraint) }
    matrix.solve { |solution| return convert(solution) }
    nil
  end

  private

  def self.constraints(sudoku)
    return enum_for(:constraints, sudoku) unless block_given?

    (0...9).each do |row|
      (0...9).each do |column|

        # Cell constraint.
        cell_cons = ("0"*((row * 9) + column)) + "1"
        cell_cons << "0" * (81 - cell_cons.length)

        # Block number.
        sub_grid = (column / 3) + (3 * (row / 3))

        (0...9).each do |num_index|
          string = cell_cons.dup
          string << constraint(row,      num_index)
          string << constraint(column,   num_index)
          string << constraint(sub_grid, num_index)

          num = (num_index + 1).to_s

          # Add if number is given.
          if sudoku.rows[row][column] == num
            yield string
            next
          end

          # Row skip - row already contains n.
          next if sudoku.rows[row].include? num

          # Column skip - column already contains n.
          next if sudoku.columns[column].include? num

          # Block skip - sub_grid already contains n.
          next if sudoku.sub_grids[sub_grid].include? num

          yield string
        end
      end
    end
  end

  def self.constraint(type_index, num_index)
    "0"*9*type_index + "0"*num_index + "1" + "0" * (80 - 9*type_index - num_index)
  end

  def self.convert(rows)
    string = Array.new(81)

    rows.each do |row|
      chunks = row.scan(/.{81}/)
      cell   = chunks[0].index("1")
      row    = cell / 9
      column = cell % 9

      n = chunks[1].sub("0"*row*9, "").index("1") + 1
      string[cell] = n
    end
    Sudoku.new(string.join)
  end
end

Details on how to implement Algorithm X can be found on the wiki page here and the accompanying dancing links page here.

Usage

Complete files to download:

$ ruby -v
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
$ irb
>> conf.echo = false # Turn off printing return value.
>> load 'sudoku.rb'; load 'brute_force.rb'; load 'backtracking.rb'; load 'dancing_links.rb'
>> s = Sudoku.new("5346789126721...4819834256.85976142342685379....9248569615372842.7419635345286..9")
>> puts s.solve(BruteForce)
# Many years later...
534678912672195348198342567859761423426853791713924856961537284287419635345286179
>> puts s.solve(Backtracking)
534678912672195348198342567859761423426853791713924856961537284287419635345286179
>> puts s.solve(DancingLinks)
534678912672195348198342567859761423426853791713924856961537284287419635345286179
>> exit

Benchmarks

Ideally the same method would be used to benchmark each algorithm however the brute force algorithm is ridiculously slow so it is discussed separately first.

The brute force algorithm took 1714.2 seconds to cycle through 88888888 possible candidates, ~1e-71% of the total number. At worst it would take 1.7142e+76 seconds, or ~5.43e+68 years, to iterate through all candidates. The best case, that the first candidate is a valid solution, takes effectively 0 time thus, on average, it only takes 8.571e+75 years to find a solution!

The remaining two algorithms were benchmarked by recording the average time taken to solve sets of 20000 puzzles, each with a decreasing number of givens.

The sets can be found here.

The plot above shows that the dancing links algorithm runs in linear time whilst the backtracking algorithm runs in polynomial time. It should be noted, however, that some of the backtracking algorithm’s large increase in average solve time may be due to cache misses, I’ll update this post after I’ve had time to fully explore this.

Actual numbers can be found here

The above benchmarks were run on my Acer C720 Chromebook running Arch Linux. Processor specs:

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 69
Model name:            Intel(R) Celeron(R) 2955U @ 1.40GHz
Stepping:              1
CPU MHz:               1400.000
CPU max MHz:           1400.0000
CPU min MHz:           800.0000
BogoMIPS:              2794.84
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              2048K
NUMA node0 CPU(s):     0,1