Today I think we’ll see about using Flood erdirectly, perhaps removing the convenience method on Cell, but adding some to Flooder.

By taking this approach, we need to be aware that we are making a pretty firm commitment to Flood. Before we remove the flood method on Cell, all our tests and code will have to be using Flood directly. In a large application, we might n...

An exchange with Bill triggers some ideas for the flood. It’s 0330 hours. Let’s see what we can do.

I woke up and can’t get back to sleep. Since I have a couple of ideas for the flood, I decided to get up and work on them. I have a few things in mind, one of them slightly larger than the others.

Rename the frontier and examined variables for clarity, and any o...

The flood method is my current darling. Should we kill it? Is it just too cool to live? Let’s examine it.

There are at least two reasons why I’d consider code “too cool to live”. The first reason is often triggered by recognizing that I want to show it off as particularly clever. It’s not that there is no place for cleverness: it can often pay off, in small enough, ...

Today we start by actually finding furthest points. We need also to remove the path map code. And maybe a “final” look at the new generate code. The morning goes well: geek joy FTW!

The point of our work over the past few articles has been to find cells that are maximally distance, along existing paths, from a given cell. The reason for passing a function into the g...

I think the new generator is working well. Let’s see if we can improve the way it’s written. A very nice refactoring sequence, if I do say so myself. Thanks to Bill for the nudge.

It’s interesting how a simple comment about the code can trigger a new look and serve as the “root cause” of a better idea. That has certainly happened after