Brute Force and Intuition


Previously I said I didn't know how to put something into words, but now I do.

In the documentary, Gary Kasparov said something like "humans see the harmony of the pieces", which you'll understand if you've ever played chess with long time controls. Being able to do this means that you don't have to resort to brute force, because you can see some kind of useful underlying structure when you look at a position. Better chess players are even better at this, and sometimes people are surprised to hear how few moves grandmasters consider each turn, because they've spent time developing an intuition for the most efficient way to spend time. This is the fundamental advantage humans have over computers. They can take these big shortcuts based on intuition.

It's reasonably clear that people do this in chess, but it's less obvious in other fields. People who have good intuition in a certain field get to take certain other kinds of "shortcuts", and do things that seem like magic to people taking an algorithmic or mechanical approach. This pattern recognition or general knowledge allows you to do things like noticing that (2 + 2i)12 is (2 + 2i)8+4, and that by repeated squaring you can find

at which point you can do -64 × 4096 = -262144, which is probably faster overall than doing this by some other method.


An example involving Richard Feynmann is a story about how he 1v1ed someone who was using an abacus, and used a pattern-matching/general knowledge shortcut to calculate a cube root faster. From "Surely, You're Joking, Mr. Feynman!", ISBN 0393316041:

The number was 1729.03. I happened to know that a cubic foot contains 1728 cubic inches, so the answer is a tiny bit more than 12. The excess, 1.03 is only one part in nearly 2000, and I had learned in calculus that for small fractions, the cube root's excess is one-third of the number's excess. So all I had to do is find the fraction 1/1728, and multiply by 4 (divide by 3 and multiply by 12). So I was able to pull out a whole lot of digits that way.

after which he goes on to explain:

I realized something: he doesn't know numbers. With the abacus, you don't have to memorize a lot of arithmetic combinations; all you have to do is to learn to push the little beads up and down. You don't have to memorize 9 + 7 = 16; you just know that when you add 9, you push a ten's bead up and pull a one's bead down. So we're slower at basic arithmetic, but we know numbers.

Still, I think it's important to not rely too heavily on incidental tricks like this, though obviously it's good to be able to jump on the opportunity when it arises. The problem comes when you don't know the general algorithmic solution to something, like how a chess player who doesn't know procedural theoretical endgame solutions could lose an endgame to a "worse" player who plays by following a few simple principles, almost algorithmically.

Getting by with as little "knowledge" as possible, and relying on creativity or insight or intuition or whatever way you want to look at this, is kind of fun, but ultimately I think it's good to take advantage of the capacity to execute algorithms, memorise data, or calculate directly, and find ways to practice the brute force methods to the point where it sometimes becomes quicker to just do something directly instead of dealing with the added cost of thinking of a faster way to do it.

As for how to implement this strategy practically, I'm still experimenting. Currently, I'm not really trying to improve at brute force strategies due to life circumstances, but it's something I want to experiment with when that changes.


I finished the cube implementation for my algsheet generator. The following enum values are used as indexes into an array of 54 stickers representing the cubes.

enum {

If you look closely, you'll notice that the stickers are listed anticlockwise around each centre piece, which means it's relatively easy to shift them along to do a "turn". That saved me a lot of data entry, since before I came up with this idea I was doing every sticker manually. That was too boring and tedious to continue with so I waited until I thought of a shortcut. So much for brute force ;p.

Though in this instance I think this is objectively better than doing it "manually", because it means less places for incorrect data entry, which is the main source of problems for this kind of program. No compiler feature is going to help you with that, so you just have to check that you've written the right letters, which is a lot easier when there's less letters. For a similar reason, I wrote a cycle4() function, which takes 4 of these indexes and cycles the values in them. This saved me some data entry and let me spot a bug more easily.

It might seem that because of those other benefits to trying to write as little code as possible (within reason), that the brute force approach doesn't really apply to programming. I think this is kind of true, since less code is usually better, but on the other hand being fast at writing brute force solutions means you can churn out prototypes and get feedback on what works, rather than meditating on the perfect solution and not making meaningful progress on your project until you figure it out.

(This is why it's good to have "boring parts" of projects, so you can do those kinds of mindless things and still make progress while you try and solve some deeper conceptual problem in the meantime.)

Parting Words

It's not so much that you can see the harmony of the pieces, it's that you have to because you're incapable of processing such a large amount of data in such a short amount of time. Being too attached to my pattern matching ability meant I didn't spend time memorising words when learning languages, which meant that when I came across new words, I didn't have the data about what the word meant stored in my brain, which meant more interruptions to look up words when reading, which was discouraging, so I read less often and got less out of it when I did. Memorising the dictionary isn't the same as learning vocabulary, but it makes the process a lot faster, because you don't have to look up words all the time. That doesn't mean that you "know words", as Feynmann might have put it, but this time brute force is the shortcut that allows you to use your time practicing a language more effectively.