Interesting idea, not least because Sudoku solving is a “solved problem”, and nothing sets me off like one of those. There are well-known constraint-satisfaction methods for constructing and solving Sudoku grids; there are branch-and-bound and integer programming approaches; you can even create, solve and typeset Sudoku grids by just typing a little LaTeX code. And of course Peter Norvig has shown us all how to do it in his excellent and clear pedagogic essay.

But of course all of those approaches make sense. Which is to say they’re elegant and no doubt ever so efficient and rational, but… well, they’re boring, for lack of a better term.

Zee and I paired a few months back on a preliminary experiment he’d designed, in which he was evolving solutions to fixed Sudoku puzzles. And something he said reminded me of an old unexplored notebook question regarding constraint-satisfaction puzzles generally, which I brought up. This week I’m in Cleveland working with him on his interpretation of that approach.

Cellular Sudoku

All the extant Sudoku solver algorithms I’m aware of rely on what you might call “serial attention” and a traditional dynamic programming architecture. That is, they scan over the initial grid in some way looking for any of a number of patterns: a block or row or column that has almost everything filled in, or a cell where two or three constraints overlap to make a number choice certain, and they fill those numbers in and start looking at the consequences. The fancy ones keep a little “stack” of what-if explorations in mind, looking not merely at the currently-obvious constraint-overlaps but also checking for conflicts and effects two or more steps into “the future”. This is in some sense the way many people actually work Sudoku: a cycle of scanning for patterns, making judicious assertions, and maybe backing out if those assertions are “tricky” (as they can be in difficult puzzle examples). And—at least in my case—probably there’s some guessing.

Very nice. We’re not doing that.

In this experiment we’re looking for distributed algorithms, a lot more like cellular automata rules, that simultaneously update the choices available to every cell in the Sudoku grid according to an (undiscovered) deterministic rule.

Here’s the way our hypothetical alien cellular fellows will “solve” a given puzzle:

1. Every cell in the grid is assigned a choice vector, which indicates which of the available digits (1–4 for small Sudoku, 1–9 for standard grids, and so on) that given cell might be at any given instant. The vectors aren’t probabilistic, just Boolean values indicating whether a cell could take a given value. If I represent these Booleans with 1 and 0 for brevity, then for example in a 9x9 grid the initial choice vector for any empty cell will be 111111111, and if the cell is a known hint (say a 5) the choice vector is 000010000—that is, that given cell’s choices are limited to being 5.
2. An Answer is a script of any number of lines, each line containing exactly one command. Commands have two parts: an argument and an operator.
3. The argument is a string that refers to the relative position of some other cell within the Sudoku grid: left, right, up, down, and also clockwise (cw) and counterclockwise (ccw). A cell’s left neighbor is the cell in the same row, one step to the left, modulo the grid width; that is, the left neighbor of a cell in the left column is the cell in the same row on the right column. Similar toroidal conditions apply to right, up and down. The clockwise neighbor of any cell in the grid is its preceding neighbor within its block, numbering in top-left-to-lower-right positional order, row-first. So for example, in a standard 3x3 block within a 9x9 Sudoku puzzle, the cw neighbor of the cell in the upper right corner is the leftmost cell in the next row. The cw neighbor of the cell in the lower right corner is the first block in the upper left, as well.
4. The operator represents a bitwise boolean operation to be carried out between the choice vector of the cell in question and that of the indicated argument cell. For example the command "left and" applied to a given cell in the grid will replace that cell’s choice vector with the result of applying bitwise AND to its current choice vector and that of its left neighbor.
5. For each line in an Answer, the choice vector of every cell in the grid is synchronously updated based on the current values, starting from the initial setup.
6. After the last command in the Answer has been applied, the resulting grid is interrogated. That is, every cell is sent a decide! message, and emits (with uniform probability) one of the choices encoded in its final choice vector. Cells that have ended up with no remaining choices emit a ? or 0 answer, indicating they’re unable to respond.

Needless to say by this time, this is an exploratory project, not an “optimization” problem. It’s not a case of “find the most efficient algorithm to do that”, but rather “is it even feasible that this might get closer to a solution”? Our suspicion is that it might, but aside from a bit of hand-wavy discussion of “information propagating across the grid” we have no fracking idea how a general-purpose Sudoku solver might work, if it can.

We’ll see.

In the meantime, you might already sense a few places where this scheme can be relaxed or expanded. Yes, we thought about probability vectors instead of choice vectors. Yes, we’ll start with a simple suite of operators like and, or, not, but we could get fancy with all 16 possible binary operators, or spread out into multiple arguments. Yes, we’re starting with a local neighborhood around each cell to begin with, but we could let the argument of any command be a phrase of consecutive moves like "left up left ccw". We could include access to the past state of a cell in the neighborhood definition as well. We could apply different rules to different cells at each time-step.

We have no clear idea what might happen until we give it a shot. Which will probably be the next thing we talk about.

How do we know what’s happening, and whether we think it’s good or bad?

So. I think I’ll start with some low-hanging fruit, not least because I’m wrestling with learning a new text editor, and trying to get all the fiddly bits hooked up is proving challenging. So I think I’ll build a Pizza class first.

Looking over the stories, I’m going to assume the pizza is just some kind of wrapper around an Array of slice sizes, with some fancy methods that permit initialization/reset and “eating”. Let’s start with initialization/reset.

# pizza.feature
Feature: Pizza

  Background:
    Given I have a new pizza

  Scenario: pizza slicing
    Given a list of slice sizes [1,0,7,9,3,12,33,0,0,0,2.88,2.12]
    When I slice the pizza
    Then there should be 12 slices
    And the pizza should weigh 70
    And the pizza should be whole

The pizza is “whole” because Alice hasn’t eaten the first slice, and it’s going to be treated as an array with “wrapping” boundaries by her yumminess function(s).

Cucumber reports that the first pending spec is Given I have a new pizza, so I create the appropriate step definition.

# pizza_steps.rb
Given /^I have a new pizza$/ do
  @pizza = Pizza.new
end

This fails, since I have no Pizza class.

#pizza.rb
class Pizza
end

And it passes. The next pending step is Given a list of slice sizes [1,0,7,9,3,12,33,0,0,0,2.88,2.12].

# pizza_steps.rb
Given /^a list of slice sizes (\[.+\])$/ do |slices|
  @slice_list = eval(slices)
end

That passes, since it’s not invoking the library at all, just setting a variable within the scope of the test. When I slice the pizza is next.

# pizza_steps.rb
When /^I slice the pizza$/ do
  @pizza.slice(@slice_list)
end

This calls for a tiny bit more structure in the Pizza class, but not too much.

#pizza.rb
class Pizza
  attr_accessor :slices

  def slice(size_array)
    @slices = size_array
  end
end

Next pending step is Then there should be 12 slices.

# pizza_steps.rb
Then /^there should be (\d+) slices$/ do |count|
  @pizza.slices.length.should == count.to_i
end

Which passes already. And the pizza should weigh 70

# pizza_steps.rb
Then /^the pizza should weigh (\d+)$/ do |weight|
  @pizza.weight.should == weight.to_f
end

That calls for another bit if Pizza structure. But is it an attribute, or a method? I’m thinking method; the slice weight array itself is already stored, and I assume the players will have some sort of #eat(left_slice) method that modifies that Array directly on each turn. I’ll return the sum of all slice values.

#pizza.rb
class Pizza
...
  def weight
    @slices.inject(0) {|sum,w| sum+w}
  end
end

Last step is And the pizza should be whole.

# pizza_steps.rb
Then /^the pizza should be whole$/ do
  @pizza.should be_whole
end

Interesting question: when is Pizza#whole? going to be true? As soon as my pizza is first sliced, surely. But maybe also when it’s initialized (“baked”)? Then again, the initialization method (which I haven’t needed yet) might be more useful to set up partially-eaten un-whole pizzas for testing or training. I’m all for postponing.

#pizza.rb
class Pizza
  attr_accessor :whole
  ...
  def slice(size_array)
    @slices = size_array
    @whole = true
  end

  def whole?
    whole
  end
end

All steps pass.

So Alice and Bob will be eating particular elements of Pizza#slices. And the stories make it clear there are two modes: the first slice, and then the left_slice vs right_slice. I suppose I should start with the first slice. In addition to making the pizza no longer whole?, this ought to “unwrap” the circle to create the left_slice and right_slice linearity.

# pizza.feature
...
Scenario: eating the first slice unfolds the circle
  Given the pizza is sliced into [1,2,3,4,5,6,7,8]
  When I take out piece 6
  Then the pizza should not be whole
  And the left slice should weigh 7
  And the right slice should weigh 5

I’ve made a new step here.

# pizza_steps.rb
Given /^the pizza is sliced into (\[.+\])$/ do |slices|
  @pizza.slice eval(slices)
end

That passes already, from work done in the previous scenario. Now When I take out piece 6 is the next pending step.

# pizza_steps.rb
When /^I take out piece (\d+)$/ do |which|
  @pizza.eat_first_slice(which.to_i-1)
end

I need to add Pizza#eat_first_slice to the library, though this step doesn’t actually call for it to do anything.

#pizza.rb
class Pizza
...
  def eat_first_slice(which)
  end
...

Then the pizza should not be whole

# pizza_steps.rb
Then /^the pizza should not be whole$/ do
  @pizza.should_not be_whole
end

Seems a simple thing to make that pass.

#pizza.rb
class Pizza
...
  def eat_first_slice(which)
    @whole = false
  end
...

And the left slice should weigh 7. Basically the “left” slice is the stub-end of the unwrapped circle I get when I snip out the eaten piece, and the “right” slice is the piece remaining to its left. First the steps I need (both at once, just because the symmetry is so clear):

# pizza_steps.rb
Then /^the left slice should weigh (\d+)$/ do |weight|
  @pizza.left_slice.should == weight.to_f
end

Then /^the right slice should weigh (\d+)$/ do |weight|
  @pizza.right_slice.should == weight.to_f
end

And the library code to make these pass. I fiddle a bit with the bounds-checking, but I think this will do.

#pizza.rb
class Pizza
...
  def eat_first_slice(which)
    open_circle = @slices[which+1..-1] + @slices[0...which]
    @slices = open_circle
    @whole = false
  end
...

And that seems to have done the trick.

• to use GP to develop strategies in Peter Winkler’s Pizza Eating Game;
• to use Lee Spector’s Tag Space Machine system as an architecture in my Answer Language ;
• to use a trivial Answer Factory architecture (random sampling of Answers plus some basic metaheuristic moves) to explore whether there anything like the known optimal strategies crop up

Some stories

I’m starting from an empty canvas: I’ll need to think about the representation of the problem domain, not just the architecture of the TSM answers and GP system. I spend some time reading over the arXiv paper that sparked my curiosity and Lee’s description of TSMs. I come up with a few stories, and some notes as I jot them down.

Eating the first piece isn’t like later pieces:

Before the first game move (when the pizza is whole), Alice can pick any piece at all. After she does, Bob and Alice can only pick one of the two neighbors of the growing gap.

As I mentioned when I launched this side-project, I’m thinking about the way these agents play the game as being some kind of “field generation” process. Their calculations impose some kind of “yumminess field” on the (current) set of pizza slices, and then when that calculation is done they eat the slice with the highest yumminess value. Further, I think I want to try a local process, a single calculation conducted with “this piece of pizza” as the focus, with references to the traits of other pieces being spatially relative.

The interesting thing of course is the topological difference between the whole pizza and the partially-eaten one. The whole is circular, with “left” and “right” being well-defined all the way around. But once a piece is eaten, the thing becomes “linear”, and the only choice before the agents is between the two “end” pieces of that ordered set of pieces.

In determining the “yumminess field”, this feels like it might be important. But it’s also limiting the set of agent behaviors: the first move is some kind of eat_first_piece, and all subsequent moves are eat_left_piece or eat_right_piece.

Pizza slices have weights:

every pizza slice has a numerical weight, which can be 0

This seems pretty straightforward: the goal of the players is to consume a maximum proportion of the total pizza, and “weight” seems as good as anything for tallying this up. Better than “crust”, surely… though of course they will sort in the same order.

Agent decision-making:

Agents have two yumminess functions, one for picking the first piece, and the other for later moves. The yumminess function is invoked with a reference to a specific index of the current pizza, and returns a float value. One yumminess value is calculated (in parallel) for each slice.

I’m thinking the basic yumminess calculations might include some boolean logic and arithmetic; we’ll work our way up from there as needed. The index of a slice is the input, but the algorithm can have instructions to interrogate the attributes of slices, things like its index, its weight, that sort of thing. Heck, maybe the yumminess of one slice can refer to the yumminess of its neighbors… but that may end up being complicated.

Because of the clear topological (and strategic) difference between the first slice and the later ones, I’m willing to start with a little extra complexity and have two separate functions. This seems to imply I’m thinking that every agent can play “Alice” or “Bob” roles in whatever scoring tournament I come up with. Why not? Let’s see what happens.

Yumminess ties are broken randomly:

When the maximum yumminess is assigned to multiple available slices, one is picked at random with uniform probability.

In other words: when in doubt, flip a coin or draw straws.

Yumminess functions are Tag Space Machines:

One for each. The appropriate references to external values are set up based on the slice index, the TSM is run, and then the topmost [number] is emitted as the output.

I’m not sure which “number” this might be. Do I need to differentiate between int and float? Really? I don’t have a lot of information yet about what the TSM language is going to be like. Maybe this will become more apparent as I work on that.

TSM math instructions:

The TSM should recognize float values, and have basic math instructions: add, subtract, divide, multiply, min, max, maybe a few more.

Do I really need integer as a type? After all, the notion of an “index” in the tag space itself depends on the mathematical “floor” function. Why not use floats for indices as well, taking the floor (or ceiling) as needed? Maybe this is just reals, and we’ll skip the difference until we need it.

TSM pizza instructions:

The TSM should be able to get the index and weight of the slice on which it’s applied. It can use weight_of and index_of with a numeric argument (positive or negative) to obtain values of neighboring slices.

I have an intuition this may not be enough. But we’ll see. It’s not that hard to imagine running the calculations for each slice in lock-step, and letting one TSM interrogate its neighboring TSM’s state, like with real_of to copy over a real from a neighboring slice’s stack into its own. But no need to over-design yet.

TSM logical instructions:

The TSM should have basic Boolean logician functions: and, or, not, that sort of thing.

Makes sense, because we’ll have comparisons to make.…

TSM comparison instructions:

The TSM should have comparisons like less_than, greater_than, equal and so on for reals and any other types for which they make sense.

These will create bool outputs.

TSM dynamics:

When the TSM is activated, it pops one item from its x stack; if it’s a constant it’s pushed to the appropriate stack, and if it’s an instruction it executes that instruction immediately. This continues until the x stack is empty.

This is just the definition of how TSMs run. But it does raise the question (from experience): Will there ever be TSM “programs” that don’t terminate? Will I need a step counter, and some sort of deadline? We’ll see, I guess.

TSM tag spaces:

The tag_space stack holds tag_space instances. TSM instructions for storage and lookup exist, and refer to the top tag_space in the stack based on numeric index. Each tag_space is a key-value pair store, sorted by numeric key. Lookup is inexact, returning the value for the smallest key larger than the search tag, or the first key of no key is larger. No value is returned if the tag_space is empty.

Feels as though I’ll need to create a subclass of Ruby’s Hash for this, maintaining the sort order and dealing with the inexact lookup. Shouldn’t be too complicated, but will demand some careful checks.

TSM tagging instructions:

There are instructions store, store_pair and lookup for writing and reading from the top tag_space. (see update below)

Based on Lee’s description, it sounds as though his ts_tag imaps arise somehow from the “genome” of a TSM: that is, they appear fully-formed in the x stack before we start running the code. This feels strange but intentional, and so I’ve asked him if I’m missing something.

In the meantime, I’m more comfortable having instructions that make those associations from arguments just like other instructions would use, except that the arguments for store and store_pair come from the x stack rather than the typed stacks. For instance, I’m imagining store pulls a “tag key” from the reals stack, and the next item from the x stack, and stores the item as a value associated with that key in the topmost tag_space.

What am I missing?

Well, of course I’ve not defined anything about how these supposed pizza-eating experts are going to be scored, nor how many and what kind of pizza they’ll be asked to eat, or any of that. But it feels like enough to get started with, especially as I’m waiting for Emma Tosch and Lee to help me out of the confusing bits.

In the meantime, I’ll start on the pizza first….

Update (later that day):

After a couple of clarifications from Lee, I’ve got a better handle on how the tags and tagging instructions should work.

TSM tagging instructions:

There are three kinds of what I’ll call macro instructions: store_at(N), lookup_at(N) and store_pair_at(N), where (N) is a fixed floating-point number, not an argument. These numerical values can (and probably will) vary between instances of these instructions, but not over the “life” of the individual instruction instances.

So basically what’s happening here is that the storage and retrieval of items in a tag_space always includes a particular address, not a numeric argument. This is a design decision from Lee, and seems perfectly valid to work with.

I think I can get away with a bit of abbreviation when writing TSM code, and use >8.2 to indicate the macro instruction store_at(8.2), use <-3.9 to indicate lookup_at(-3.9), and >>991.55 to indicate the macro store_pair_at(991.55).

A recent arXiv preprint entitled “How to eat 4/9 of a Pizza” caught my eye. It’s an interesting little answer to a challenge from game theory (and geometry, I suppose) posed by Peter Winkler, who’s a constant source of inspiration.

Hungry, Hungry Alice & Bob

Suppose we have a circular pizza, already cut into wedge-shaped slices (from the center to the crust). These are extremely precise slices, and in fact they can have “0 width”, or some small epsilon close enough to 0 to be entertaining.

There are two hungry players, Alice and Bob. Alice chooses a piece to eat first. Bob and Alice alternate eating pieces of pizza after that, until it’s gone, but they must both always choose one of the two pieces adjacent to the growing gap.

The arXiv preprint describes a strategy by which Alice can eat at least 4/9 of the pizza, regardless of the slices or how smart Bob’s strategy is. She may be able to eat more than 4/9, depending on the slices and Bob’s mistakes. And of course she’s only guaranteed to get that much if she’s following a provably optimal strategy.

Agents: Represent

See, I’ve been writing this book, and there are a number of little side-projects like this one that have come up, but probably won’t make the cut for the final edit. The six large-scale projects I’m working on keep me busy enough, but at the same time I’m trying to polish and refine my “simplified” approach to GP project management.

So this is me thinking in Ruby about one of those little side-projects.

I’ve also recently been watching Lee Spector’s explanations of Tag Space Machines unfold. Tag Space Machines (TSMs) are a representation scheme for GP languages he’s implemented in his lab’s work. I think I may work with TSMs here.

Pizza

The pizza is modeled as an Array of “slice weights”. An uneaten pizza is considered to be circular, and the first player (“Alice”) can eat any piece she wants. Eating the first piece “unfolds” the pizza, restructuring the array so that the start and end values are the pieces on the “right” and “left” of the gap. After that, players can only choose to eat one of the two end pieces.

In other words, the player agents have only three actions (besides “planning”): eat_first_piece, eat_left_piece and eat_right_piece. And they don’t even get free choice among those three, since the first is mutually exclusive with the last two.

How to think about eating pizza

The big design question here is, how do players think about the pizza?

A slightly more traditional approach might have them handling arrays and iterating and stuff. But having modeled game-play before, I know there’s also more distributed (if less intuitive) approach I’m wondering about here: since there are so few choices in the game, what if a “thinking” or “strategy” were a scalar field calculated locally for each of the pizza slices individually, and which slice is chosen by a given agent was determined by the highest-scoring pizza slice according to that agent’s slice field algorithm?

In other words, suppose Alice has eat_first_slice field definition that is a function applied to each element of the pizza slice array (treating it as circular). The arguments are the weight of “this” slice, and weights and distances of slices to the relative left and right of “this” slice, and the number of slices overall. Maybe her eat_first_slice field is the weight of a slice plus the average weight of its six neighbors on either side.

Alice’s first turn begins with her calculation of this field for the given pizza, and then she selects the highest-scoring slice. If Bob and Alice then have a (possibly different) function for scoring the slices of the non-circular pizza, the same dynamics can apply to their subsequent choices of left_slice over right_slice. In cases of ties, we pick at random.

Might this approach work? I have no idea. It feels as though it has some flexibility. We’ll see.

I’ll post updates as I make progress.

I realize I’ve turned quiet as far as the blogs are concerned. I’ve been working on translating the draft content for the Answer Factories book into published manuscript. Markdown is lovely, but talking in detail about the process of software development still requires an awful lot of cutting-and-pasting, it turns out….

I recently updated the published draft; if you’re behind, feel free to go update your copy now. New content includes a description of the iPad game Cargo-bot, and a detailed test-driven re-implementation of the game logic in an emulator we’ll use for GP in forthcoming chapters. I spent a lot of time on the test-driven development, so I’d like some feedback if you’re willing.

Also: Do you prefer the blog or the Google group for this sort of thing?

One of the deepest philosophical qualms I’ve had about the structure of the book is the necessity to show code in some particular programming language, without implying that if an algorithm were written in some other language it would be “better” or “worse” or in any sense functionally different. If I pick Ruby, things not only devolve into “Genetic Programming in Ruby” (which is misleading), but Python and Clojure and J programmers are left unable to follow along.

Traditionally computer scientists have use pseudocode as a solution to this problem, but to be blunt pseudocode sucks: the acceptability of runnable code should not be driven by structural features pseudocode enforces (loops, branches, arguments) but the behavior it exhibits. As far as I’m concerned it’s not only misleading but dangerous to hand out pseudocode, if nothing else because I’ve watched people treat the text as if it were a form to fill out, replacing every line of the pseudocode with an “equivalent” line of code-in-some-language, expecting the result to run as intended.

Of course in a big chunk of the readership, those familiar with test-driven and behavior-driven development, tests do the trick handily. But in the other big chunk of readers, that sensibility and suite of habits is missing, and even alien.

So here’s what I decided: I’ll write code myself, and in the beginning project show all the code I write, but only in a behavior-driven way. The Cucumber tests will be there for readers to use (or kludge along with) in their own language of choice. I’ll be working in Ruby for the first project because people who are comfortable with Ruby are the first audience I hope to reach.

But there are six projects planned, and so I’d like to gradually set the explicit code aside, and come to rely more gradually on the Cucumber features and stories, or perhaps “more generic” (?!) statements of acceptance tests the reader’s libraries should pass.

So the programming language I use in the second project is up for grabs. Clojure? Python? Javascript? Objective-C? In any case it must be something with a stable and usable acceptance testing framework on hand; I’m not scheduling any time to write my own testing libraries here.

The second project’s subject matter will either be “evolving geometric algorithms and proofs” or “data-mining and stock-trading and related crap”. So any language I’ve listed will work fine, and perhaps a few others I could learn relatively easily. (But not Java.)

Your input would be appreciated!

… Well… there it is.

It’s an interesting thing to watch from the inside. The social networks, the cliques and components forming and re-forming. I can’t help but feel I’m watching turf wars on the ground: all of us old influencers with our various Schools of Martial Arts vying for attention, revisiting old scores and reminiscing about which thing happened when, joking about In the Old Days at the same time we eye the young bloods keenly and try to steer them towards or away from Right Thought and Practice.

This is a dilute field, if it’s a field at all. One or two people in each institution, with a couple-three graduate students each. In the old days, there was still a defensive air about it, like we used to hear at Complex Systems research conferences. We’ve moved (a bit) past that stage of justifying the approach as such, convinced ourselves and our peers there’s something useful to be done with “biased random guessing”, so now the tribes are splitting along not-unexpected lines as they think about what they should seem like. Should this thing I’m doing sound like Operations Research, clad in formal provable correctness and rigorous theoretical justification? Should it sound like Artificial Intelligence, with agents believing and intending and desiring to move blocks and identify spam? Should it be a form of generative art, a way of inspiring and provoking me to new works? Should we consolidate our resources, like the Machine Learning people did, and start benchmarking so we can “better compare” results, or build tools that make it “easier” for “non-technical people” to “solve problems”?

And of course the lumping and splitting goes on, as ever: But this is just another example of that, a special case. This is new (it must be, if you’re presenting it); this is old (it must be, if you are to be given credit); that is this (it should be, if we’re to understand one another); this is not that—nothing is ever anything else. Where “this” and “that” are works, techniques, experiences, guidelines, rules, habits, terms.

Nobody talks about the community in which they work. Not this community of conference-goers, but the community of people who might someday actually want their cancer cured, or their stocks traded. The academic habits of the Cold War—deep resource deprivation, the Artificial Intelligence paradigms, the rampant cultivation of Lone Genius as the one route to greatness—they drive so many into their own work and away from helpful collaborations. There are collaborations within the families (the MIT family, the Virginia family, the Illinois family, the Stanford family, the Michigan family with its wide-ranging limbs), but still I never see people talking about how a problem becomes a project, nor how a “result” becomes a useful furthering of some conversation.

There’s discussion of subjective experience, of course. Some nice ones. But even these lie within the boundaries of the Technical Works: I was surprised to see it doing this; I tried X but eventually Y was better.

For whom?

What I’ve found so far is that my old colleagues work as though providing self-contained software were of use to anybody. They talk as though publishing self-contained repositories of data and algorithms were of use to anybody. They think, I’m afraid, that the places human beings interact with their work should be limited to the production of “requirements” and the acceptance of “results”.

They do not speak of human context.

I hope they get over it. I would like them to find something outside themselves and their particular School of Martial Arts and their own turf that brings them together in a “track”. How do we cope with fear? With hubris? How does one work, when one is working in service of some other person’s aim?

I have standard questions I ask in almost every talk I attend: Why do you ignore the other objectives? Why do you use that habit, that library? Why do you measure that thing, and not the real thing you’re doing?

I don’t ask these questions to find out their technical justification. I’m not quizzing them on how well they’ve learned to write a multiobjective non-domination algorithm, or read and write from a database. I’m asking them because I’m still waiting for one to say, “Because when we discussed it with our colleagues, the people whose question this is, they wanted to try this. It was best at the time. It was something so we could deliver results and learn together.”

I want somebody to say, “The customer saw value in it.”

But so far I fear the “customer” is represented in this work as a mere tradesman, or worse a “layman”. Somebody you help only after taking their problem away from them, Being Very Smart, and giving the Right Answer back to them so they can use it.

Such a Waterfall world. So confident, even in the face of hundreds of hours of talks discussing why things are hard and complicated and slow.

These are excuses for failing to deliver something to a person who can use it. Of course they’re cultural excuses, Cold War excuses, Academic excuses based on “significantly advancing the field”. But they justify a view in which work is yours, and problems belong to other people.

I’m finding that writing the introductory material for the book is difficult. In fact I’ll probably postpone releasing the intro until more of the core guts are written. Mainly the introductory material has been about that perennial question, “How do I find and pursue ideas?” My core argument is that GP is useful for accelerating the fruitful investigation of your ideas, but the challenge for many folks is recognizing the heuristics I personally take for granted. Some of this means I’m revisiting Polya’s How To Solve It: A New Aspect of Mathematical Method, but I find that it’s not philosophically compatible with the agile stance I personally prefer, so I’m actually finding Andrew Abbott’s Methods of Discovery: Heuristics for the Social Sciences more useful, not least because he suggests Aristotle’s four causes and Kant’s schema as interesting “kicks to the head”. And there’s Michalewicz and Fogel’s excellent How to Solve It: Modern Heuristics, which goes in a more technical direction (and closer to GP) tan Polya was able to do.

But I look over all that good advice, and I find it troubling. So I’m up in the air about it.

I decided more than a month back to change something important in the book. I still think Learning by Doing is crucial and important. But I can’t see a way to provide acceptance tests alone (with no pseudocode or worked-out examples) in an enticing-enough way that provokes reasonable responses from the readers. That is, I got a lot of pushback from potential audience members who don’t actually know how to write their own code based on acceptance tests.

Le sigh.

So I’m trying what Ron Jeffries did in his Extreme Programming Adventures in C#: describing what I am thinking, what motivates me, what I actually do, and as a result I hope to make the process itself more transparent, not just the externally visible steps. As Ron pointed out a few weeks back when we chatted about it, this smacks of arrogance. Who am I to think other people care about the mistakes I’m making, or want to be misled by watching me do stuff I subsequently undo? Just to prove I “learn something” from it?

Them’s the breaks. The alternative would be the crap one already has: pseudocode presented as if it were the one “right” way to do stuff, and the inclusion of idiomatic (or worse, generic) libraries that the reader should re-create themselves for every project, not borrow and re-use indiscriminately just because it happened to be in a book. In other words, better sorry than unsafe.

So inspiration is a thing I’ll set aside and talk about subjectively, not in terms of heuristics which (as Abbott points out in his excellent account) can quickly become fossilized and ritualized as though they were “correct” instead of useful.

So I picked up a book

I seem to like mathematical recreations. Just the other day I sketched a little game thing that somebody should pick up and run with. If it sits around long enough, maybe I’ll do it myself, but not until the book is farther along.

In the pile of interlibrary loans that I picked up the other day was a treasure trove in one volume: Geometric Folding Algorithms: Linkages, Origami, Polyhedra. Now the mathematics of origami and stuff is all modern and weird and “advanced” to my generation; most of the actual mathematical results came after I graduated from University, and appeared in fancy esoteric mathematics journals even then. But there’s a constant chorus in New Scientist and Science News and stuff about new results, and there’s this other thing I used to do when I was a structural biologist that involves folding and abstractions of physical reality surprisingly similar to those in origami. Which is the Holy Grail of a multi-trillion dollar industry at the moment, by the way.

I’m trying to put my finger on what it is about some books— Martin Gardner’s or Cliff Pickover’s or Ivan Moscovitch’s, for example—that makes them so inspiring. Is it the density of open questions? A tone that makes you wonder before disclosing anything? Something inherent in this semi-abstracted recreational game stuff that makes it clear how to write a simple computer program but unclear how to solve a problem? Something about puzzles? I have no idea.

At any rate, this one has that same stuff on it. It’s fun.

I picked it up from the stack this morning, opened to a random page, and started reading about one-dimensional origami. Now this is a book that’s framing new work in modeling physical systems like folded paper (and proteins) by setting up the mathematical constructs and abstractions in a traditional way. But there’s a heuristic I find myself adding to the other handy “kicks to the head”, especially useful for GP work: What would it take to build a software system that “did” this?

So let’s think about one-dimensional origami for a second.

Does it fold?

Before they even get very far in the formal mathematics of paper-folding, Demaine and O’Rourke talk a bit about representing one-dimensional folded structures. You know, the traditional necessary and sufficient conditions for determining whether a thing is what you call it or not. Those core concepts, the stuff hanging off the “trivial” parts of traditional science and engineering that you often elide because you’re just defining your terms, that’s where there’s often low-hanging fruit for GP projects.

I recommend a browse through the excellent book, or just peek at Erik Demaine’s lecture notes on the subject. We’re talking about what starts out as a line segment, which we crease at certain (arbitrary) points, and then press flat so that it produces a sort of accordioned stack of squiggles. Think of a cross-section through a piece of folded paper.

Let’s use paper, for a minute, and just assume for now we are folding it only in the vertical direction. Just to get a slightly more visceral sense of it.

Plop a (big) sheet of paper down on the table in front of your mind’s eye for me, OK?

We can make “mountain” or “valley” folds. Think of a “valley” fold as taking either the left or right edge of the paper and folding it upwards and across towards the opposite; think of “mountain” folds as tucking the right or left edge down underneath the stack. You can make these mountain or valley folds anywhere between the edges of the paper, and as long as the creases are parallel with the left and right sides you’re mimicking one-dimensional folding. Just peek at the end of the sheet to lose the extra dimension.

There’s a tricky bit of mathematics hidden inside this simple-seeming physical model, though: how do we capture the physical constraint that keeps paper from passing through itself?

Demaine and O’Rourke’s contributions are eminent and interesting and well-considered. There are cunningly-crafted constraints that capture the physicality of paper’s inability to cross itself, and identify feasible flat foldings (and implicitly foldings that aren’t “flat” at all), while maintaining the integrity of the paper itself. In other words, you carry on that direction, and you have a formal representation that lets you do some fascinating mathematics and modeling.

But what would it take to build a software system that “did” this?

By “this” I mean the work of establishing necessary and sufficient conditions for realistic folded lines. The implicit and tacit stuff a human being takes for granted when they have some notion of “crossing” or even “folding” in their heads already.

Does this make sense?

So let’s ask a GP system to look at a stack of line segments of various lengths and “merely” say whether there is any way a single line segment could have been folded that way, without crossing itself. Heck, there are probably long-range situations in which a partially-folded crumple would interfere with itself; let’s ignore those.

So here’s a quick sketch to help out:

The top two squiggles are actual folded line segments.

The first is definitely feasible, in the sense that you can imagine crunching up a pipe cleaner or folding the edges-only paper I mentioned above and making the cross section look like that.

The second it infeasible, because the middle leaf is too big for the space it’s in, and protrudes through the crease.

But I think we need to go farther for this to be reasonably interesting. Think about how you would represent these objects or situations in your GP system. What is a “folded stack”? Do you start from a line segment and introduce mountain and valley folds at certain positions in some order? Or do you start from the folded stack and represent it as a series of orders in certain positions, like those I’ve shown below?

I’ve sketched five little situations down there in the bottom, indicating with the dotted green lines where the nominal “crease” points are. Which of those five might be feasible? Which of them are feasible but represent a line segment that’s not the same size as the original shown in the top two? Which if them is infeasible even when you allow the raw material to be any size at all?

See how this works? Those are all reasonably interesting questions. I can totally see a set of a few hundred (or thousand) examples and counterexamples for each category. Some examples (I assume) from every combination of feasible/infeasible, same/different, congruent/incongruent, single/multiple pieces. It’s an interesting algorithmic exercise to fill in that chart with diagrammatic examples. Training and test data are yours for the taking then.

But what this sort of project wants from us, as GP folks, is a bit of ontological work.

I’m the one who does this for a living, so let me preempt your versions now:

• a Diagram is a list of Stretches
• each Stretch has a numeric length attribute, and a list Segments attribute
• each Segments list contains integers representing the segments present, in top-to-bottom order, numbered from 1 at the top and increasing downwards

So for the five examples I’ve shown, each would have three Stretches. Say their lengths are 4, 11, and 5 respectively. And the Stretches would contain these Segments lists, respectively:

1. [1],[1,2,3],[2]
2. [1],[1,2,3],[3]
3. [1,2],[1,2],[1,3]
4. [1,3],[1,2,3],[3]
5. [1,2],[2,3],[2]

Notice that the only difference between the feasible and infeasible examples (the first two) is the third Segment. What sort of “thinking work” does your GP-developed algorithm need to do in order to differentiate usefully between these?

Notice that the first and third are both feasible, but that the third doesn’t add up to the same amount of material. Again, what does your GP-developed algorithm need to “know” to be able to identify which diagrams might and which might not be the same line? On the other hand, if we think of the Segment lengths as proportions rather than explicit measurements, we’re suddenly allowing the third diagram as well; in some sense it’s congruent to the first, but not identical.

And so on.

What sort of manipulations of these input structures might a general-purpose classification algorithm do? What, in other words, is the Answer Language like?