Category: sudoku

Another quick look for something needing improvement.

Let's see what else might use a little improvement.

Still looking at that 20 line class. Yes, I think it needs improvement. Am I serious? I think I am.

I think we're nearly done with Sudoku at least for now. Let's look at the code and see what we can say about it. We find an issue in the first 20 lines. Wow.

After a review of notes, we move component looping from one class to another, in seven very smooth moves. I forgot to commit two of them, but it was still quite smooth.

Let's review our notes and see what to do next. Is there a way to wrap this up semi-neatly? Quasi-neatly? Not yet, but progress is good.

I believe that our naked and hidden pairs code was reporting that it had changed things when it had not. That would be bad. Let's see about doing it better.

Before we plug in the new Techniques, let's work on the 'Making App' with a very small Logger. Very mediocre results this morning. Meh.

Let's review our list and see what needs work. I want to try super tiny steps today, just as a matter of practice. (cf. Charles Beaudelaire)

We seem to have working code for hidden pairs. It is not yet a suitable object: more of a working prototype. Let's step back half a step and assess where we are and what to do next. We narrowly avoid a bear bite.

I think we're ready to try to find a real hidden pairs situation and adjust the notes accordingly. I am sure we're going to find an interfacing issue that will be a bit interesting. Includes notes on 'think-squared'.

Soon, dear, soon. We have the ability to set up a test. Let's see whether that sketched Hidden Pairs idea will work. I think there is at least one more stop before we're there, though.

Now that we have our foot in the door with `find_candidates_pairs` tacking a condition function, what would we have to say to define hidden pairs? Spoiler: We improve our ability to test.

As I think about additional Techniques, I believe I need more help from my objects. I have an idea to try out. Well, part of an idea.

Well, the new 'lonely' technique needs better testing and maybe a better name. I really want to do an unneeded optimization. There is grunt work to do. PyCharm earns a biscuit.

If, in the candidates for a given component, a value appears in only one candidate list, then that value must be assigned to the corresponding cell.

I wonder whether it would be that difficult to have constant Component instances rather than creating them dynamically? Kent Beck haunts me.

Yesterday's work useless. Last three days generally ragged. Today, I'll try to be more focused and go for speed. See Kerth's Prime Directive.

Based on input from my betters, I work on a faster way to deal with Candidates. GeePaw puts a word to it. Probably the wrong word. I go off on a tangent and discover profiling. An odd morning, with some interesting discoveries and one nice tiny object.

Having come up with the word 'evolving', I am ready to tilt once more at the windmill. Will I succeed this time? Spoiler: Yeah but U G L Y!

Tomas has been nerd-sniped and is solving Sudoku with Haskell. I nerd-snipe myself, thinking about Haskell, immutability, and updating. Some learning, almost no progress.

The Naked Pairs (NAIAIS) technique seems to work. What should we do next? I feel that we should step away from the brute force solver.

Ron, you keep changing the design all the time! Why don't you just nail down the design once and for all, and move on?

Did you ever look at your code? I mean REALLY look at it? This is going to be good! And it is!

I thought that I had made a misteak, but now I think I was wrong. I refactor to very small methods. Too far? Not for me, what about you?

Well, naked pairs, still, but I've used up that title. Brother Bill raises a question. I think we're OK. Let's try to implement the idea, whatever it is. Result: it goes very nicely.

Still not as interesting as it sounds, but this morning I plan to hunt down some naked pairs. I foresee some issues. And what about that pending issue from yesterday? Results: a bit long, but some shape emerges.

I've found some Python code for Sudoku techniques. I do not like it. But it'll be useful, I reckon, even though we aren't likely to copy it.

Reflection on how things are going makes me think we need to change direction a bit. Can we manage it without rewriting a lot of code? Can we keep all or most of our existing test working? Let's find out.

We already know of one more 'smart' technique that we might apply, but it seems a bit tricky. And how can we provide a 'menu' of techniques to be applied? Is this Big Design Up Front?

Let's fix that reminder test and set up to allow us to select techniques. A bit of progress, and raggedness tells me I need a break. It's artificial, it's intelligent, and it's not AI.

Let's try to put some intelligence up in this thing. Not artificial, mind you, though it will involve code. Spoiler: Works well and we learn a bit.

Tomas provides a clue. Whatever might we do with it? Ideas, experiments, and a decision not to go ahead with the ideas ... yet.

This thing just keeps on giving. I want to check something out. Result surprises me and I'll need to do some more thinking. Got good ideas? Let me know!

Is this a game of Sudoku, or a game of Columbo? I keep finding things to do! Fewer classes, a bit more clear ... but a few more lines of code.

It has been a while since I looked at the Sudoku code. I don't have anything in mind for it, but let's see what we can find just by looking.

I've thought of an object that we probably need. Let's find out. Result: A very pleasant refactoring sequence leading to a design that I prefer. Click to find out why.

What does all this have to do with real programming? We'll begin with last night's FGNO and go wild from there. We mention Iceland, and the age of the universe. Onions. Easter eggs.

I've come up with something that I think will be much nicer for computing the base positions from which to fetch our rows, columns, and sub-grids. A little refactoring does improve things, I think.

Let's review the code and the "project", to see what, if anything, we can conclude.

My theory is that once the sub-grid calculation is added to the Puzzle, we should be able to solve a 9x9. Let's find out.

The trivial test for my initial solver sketch passed. Will it hold up? Let's find out.

If the code agrees with me, I think I'd like to sketch a tiny solver this morning. Let's see if that's feasible. (Spoiler: It is.)

Let's see about getting the column, row and sub-grid for a given array index.

We spoke of Sudoku at FGNO, and my 'failure' with it, and with me, apparently, the failure of TDD, Extreme Programming and all of Computer Science.

I wasn't really planning to write about Sudoku again, but here we are.

The code is beginning to ask for some help. We're processing a simple array of cells instead of an object, and the classes don't feel cohesive. Let's push some methods off to new classes and see what happens.

A little more explanation of what I'm up to, and a test of a method that actually figures out what could go in a cell. Whee!

A number of people on the tdd list have reported having a lot of fun TDD programming the game of Sudoku. I've not played the game, though of course I've tripped over the piles of books in the bookstores and at the airport. But discussion of the thing makes it sound like it might be fun to TDD on it, as people are saying. Let's get started.

The program reached an impossible state during the first test of the algorithm that I turned loose. I thought I had made a mistake, but it turned out I had not. Well, not a coding mistake.