me@localhost:~> bc
d=1; for(i=21; i < 41; i++){d *= i;}; print d; print "\n";
335367096786357081410764800000
n = 1; for(i = 1; i < 21; i++){n *= i;}; print n; print "\n";
2432902008176640000
d/n;
137846528820
I couldn't start Python for some reason, so I went 1337 and used BC, which comes preinstalled in every Unix-like OS. BC has a surprising advantage here since 40!/20! cannot be represented as a 64-bit integer since its value exceeds 2^64. That said, BC's stdlib does not provide the factorial function* - so I had to resort to using for-loops instead.
* - What it does contain is sine, cosine, exponential, log, arctan, and Bessel J (?!?!?!?!)
An intuitive motivation for the solution in the article (2n choose n). For an n*n grid you have to you will take 2n steps, n "over" and n "down". All that matters is the order of the steps. So if you think of there being 2n "slots", you have to pick n to be "over", and the rest are forced to be "down". So it's n choose 2n indeed.
You can also think of it another way, without using the formula combinations, and only the fact that there are n! permutations of n objects. We can think of this a permutation of 2n items, made up of two groups of n identical items each. Using (2n!) will overcount, due to the fact that each of the "over" steps are identical, and similarly for the "down" group. We have cut down our answer by dividing out all of the repeated sequences. There will be n! redundancies for all the ways we can permute the "over" group and, the same for the "down" group. So this results in (2n!) / (n! * n!), which is exactly equal to 2n choose n. See [1] which explains permutations with repetion this in general. [Note: We pretty much re-derived the formula for combinations!]
Just noticed this, but intriguingly, Catalan numbers are (2n C n)/(n+1), which hints at a connection with trees.
Off the cuff, notice that the diagonal has n+1 intersection points, and a path that never passes through the diagonal gives a forest via the isomorphism with ballot sequences [0]. Any sequence that does pass below the diagonal can be "rotated" into one that doesn't, and so there are probably n+1 paths in each "path class" on average.
Conversely, this would suggest that all paths contained in just one upper or lower triangle of the square can be counted by the Catalan numbers. Indeed, a 2x2 square has just 2 such paths and (2n C n)/(n+1) = 6/3 = 2.
The way I thought about it: to get to the goal you have to do 20 steps: 10 times right, 10 times down. But the order of these steps does not matter, ever possible arrangement is a solution.
So for counting, you can basically think about it as a list of twenty initially empty spots. You first fill it in with your 10 down steps. The remaining 10 spots will then be the ones for the 10 right steps. So really the only choice you have to make is where to place the 10 down steps.
This question boils down to: in how many different ways can you distribute the 10 down steps over the 20 empty spots? That's 20 choose 10.
I made myself reason it out, and came up with the exact same intuition. You need a sequence of 2n moves (n down moves, n over moves), but the sequence is completely determined by which moves are down (the others must be over). So it's 2n (moves) choose n (over).
Ha. When I found that problem I draw the grids and paths from the example, left for a coffee and when came back I just look at the drawings at an angle and thought "well this is just Pascal's triangle". And the solution was obvious.
Noticing a pattern and just extending it without proving why it works is not really a solution. You can prove it without really "understanding" it using induction, but that still would be proof, same as just counting on a computer.
I think one of the saddest thing is that the kind of person who would recognize, "we can solve this seemingly complicated problem by just applying this formula", would often have trouble even getting recognized in many corporate environments.
I managed a guy like that. He was capable of very complex thinking, but he wasn't in love with complexity, he was in love with simplicity. His solutions tended to be of the form, "we can ignore all these things, and just focus on X, and it will provide all the value." He'd notice something and simplify it and the benefit to the company would be measured in multiples of his salary.
Every manager who'd ever directly managed him knew what a treasure he was, but it was often hard for us to convince others of the value of his solutions because they were so simple, and people were convinced that hard problems must have complex solutions. (or else they would have solved them, right?)
He eventually got bored. He retired and joined a seminary.
> I managed a guy like that. He was capable of very complex thinking, but he wasn't in love with complexity, he was in love with simplicity. His solutions tended to be of the form, "we can ignore all these things, and just focus on X, and it will provide all the value." He'd notice something and simplify it and the benefit to the company would be measured in multiples of his salary.
I did some of that a few times in my life. But I also realised that a large part of the value I brought was not necessarily in coming up with the solution, but in convincing the rest of the company---and in training up enough of the rest of the team to understand and maintain the system.
For example at Goldman, I used an integer linear programming solver to re-shuffle how we assigned compute capacity in different data centres to various departments and how to compute fail-over plans ahead of time.
The actual modelling and implementing barely took any time at all; I used an off-the-shelf open source solver. But I spend multiple weeks teaching the team enough about linear programming so that they can eg change the model when business requirements change.
I have the opposite experience with this, and I personally also default to simplest solutions at least as a baseline. However it’s important to distinguish between simple solutions that approximate the problem very well, to simple solutions that work in limited context or with heavy sacrifice in assumptions because those will hurt you in the long run.
Even if you don’t know or remember the basics of combinatorics you can solve the problem with basic dynamic programming : start with the unit grid and then expend it.
Heh, this grid image is all too familiar to me right now.
I’m building a grid based game and engine, and I have a game replay format which is not video.
I hit a massive wall with compression, trying to compress unit pathing and was trying to solve a similar solution.
Given an NxN grid, and the 4 cardinal directions (NSEW) you can move in, plus an extra action that makes you move 2 cells instead of 1, and considering you can move 4 cells per second…
What’s the smallest worst-case raw compression artefact you can output for 1 player for a 1 minute game?
It’s an extremely fun problem to solve. I tried:
- encoding changes into bits eg using 2 bits for direction
- movement pattern batching (ie batching 2 moves into 3 bits)
- crowd patterns and movement prediction
- treating movement as a “projectile” and deriving intermediate states
And all sorts of other wild crap that I will write up about on game launch
There’s a bit of hand-waving in the jump to 2n choose n solution, which I suppose is fine, and my ex–math teacher brain really wants to have a proper proof or at least solid reasoning rather than “it follows the pattern” based on three observations.
But I am reminded of how during my engagement 24 years ago, my future father-in-law raised an issue of being able to determine whether they were getting the full amount of sandpaper on large rolls that they were paying for. I was able to simplify the question a bit to one that treated the rolls as if they were simple concentric rolls of a specified thickness and from there could turn it into the good old Gaussian sum formula times 2π to get the length. The engineers working for the company came up with the same solution, but instead of using n(n-1)/2 they did the summation with multiple rows in excel.
There is no easy way out, you have to rest but you simply can't stop. Your body will rot, your mind too.
PS: song isn't an ode to the grind culture or how to slave away in an office, as lyrics say "you’ve got to work for yourself - Love yourself, feed yourself".
That Project Euler problem was my first encounter with memoization. At the time, it felt like a magical solution, so I ended up solving it using the central column of Pascal's triangle, which was easier for me to understand back then.
I also tried a weird idea involving popcount, but it didn't scale. My approach was to represent each possible path with 0s (don't turn) and 1s (turn), testing the same number of 0s and 1s. However, even with popcount running in O(1) with hardware support, the total number of possible paths made the idea impractical :)
I was sad in a different way. I immediately realized that this could be solved by dynamic programming by computing the recurrence F(x,y)=F(x-1,y)+F(x,y-1) with the base case F(0,0)=1 and F(x,y)=0 if x<0 or y<0. The problem is that I immediately jumped to generating functions as a tool to solve this. I defined G(u,v)=\sum_x \sum_y F(x,y) u^x v^y. After maybe ten minutes of manipulation I arrived at the closed form for G(u,v)=1/(1-u-v). At this point I recognized its series expansion and its coefficients are just given by the binomial theorem.
I feel sad because I had forgotten the simple and intuitive construction of choosing “go down” and “go right” directions. When a person learns more advanced mathematics, it is often the case that the person just applies such advanced mathematics by rote without realizing that a solution can be found with more elementary mathematics and more creativity. It reminded me of the time in middle school before derivatives were taught, when my teacher reminded me that using derivatives to solve a problem would receive no credit.
There is nothing wrong in using generating functions. A very handy and powerful tool. I wish I was better at it than I am.
It is a common experience in mathematical problem solving that the first solution leads to more insight which illuminates a shorter slap-my-forehead solution -- bruised forehead.
This is a pre-AI phenomena. I observe it quite a lot with stuff I did in high school but usually with complex problems. What's generally happening is that you were working with pen and paper through a hard problem. With adult brain, you'd expect just to know the answers, but in reality you're not much smarter than you were at 14, so you need to do the thing properly.
Also if you help little kids with homework, you'll see that some problems are quite difficult as well and require you to actually think, even if it's problems for 10 year olds.
We taught this problem in my college’s discrete math course. The intuition we gave is that it’s exactly equivalent to the number of ways to rearrange a string of 20 Rs and 20 Ds (corresponding to a right and down move)
The trick to making these problems intuitive is to mentally rewrite them into a "how many permutations of this string are possible?" problem. Consider the 2 * 3 case.
...
...
One way you might get there is
Right, right, right, down, down
Then you can rewrite this as
RRRDD
You will always need 3 R's, and you will always need 2 D's. So how many unique strings can be made with this?
Well let's actually consider the degenerate cases.
ABCDE
there are 5 places A can go, then 4 left B can go, then 3 left C can go, and so on, until we get 5! = 120 possible permutations of ABCDE. If you replace the B with another A to get
AACDE
now there are only 60 permutations, because half of the original 120 only differed by where the A and the B were relative to one another. By that same logic,
AACCE
has only 30 combinations, and
AACCC
has only 10 (seeing why it's 10 and not 20 is actually the trickiest part imo, it's because there are 3! ways to arrange CDE, but only 1 to arrange CCC).
AACCC is isomorphic to RRDDD, which is how we get 10 possible paths to solve the 2*3 grid. We can check this with the binomial theorem: ((2+3) choose 3) = 10.
What's nice about this step by step approach is that it generalizes not just to non-square grids, but to multiple dimensions as well! Imagine trying to get from the top of a 3 by 3 by 3 Rubik's cube to the bottom, how do you do that? Well how many ways are there to rewrite
AAABBBCCC
? The logic above would suggest 9! / (3! 3! 3!) = 1,680 unique paths. And you can just derive it by starting from the degenerate case and figuring out how to slice things up!
This is also me. I was a double CS and Math major in university and one of my favorite classes as a young lad was combinatorics and probability.. 25 years ago..
It's true, if you don't activate this area of your brain often, it's easier to brute force the solution and reach for the easy mechanical calculation. I can feel this when I'm refactoring code. Today, I just have Claude do it for me with a few instructions. Each day, I feel a tiny bit more ignorant about the actual framework's APIs, its abstractions, and its rules. But I still would rather do other things with my time.
As for the problem, luckily for me, this one was easy to derive if you remember factorials, permutations, and remember to account for duplicate patterns
The 2n choose n solution isn't at all intuitive to me but thinking about it in terms of 40 steps, 20 of them rightward and 20 of them downward an then looking at all distinct permutations of these 40 steps as (40!) / ((20!)^2) is intuitive to me. Then it becomes obvious that since 20 is half of 40, k and n - k are the same number (20), which coincides with the binomial coefficient n! / k!(n - k)!. But this seems like a lucky coincidence in 2 dimensions and if you extended the problem into 3D you'd do better thinking about permutations.
Manhattan distance is 2n steps. Of these, exactly n are to the right, the rest is downwards. A 2n step path is completely determined by choosing which n steps will be to the right. Hence 2n choose n.
60 comments
[ 3.5 ms ] story [ 64.2 ms ] thread* - What it does contain is sine, cosine, exponential, log, arctan, and Bessel J (?!?!?!?!)
You can also think of it another way, without using the formula combinations, and only the fact that there are n! permutations of n objects. We can think of this a permutation of 2n items, made up of two groups of n identical items each. Using (2n!) will overcount, due to the fact that each of the "over" steps are identical, and similarly for the "down" group. We have cut down our answer by dividing out all of the repeated sequences. There will be n! redundancies for all the ways we can permute the "over" group and, the same for the "down" group. So this results in (2n!) / (n! * n!), which is exactly equal to 2n choose n. See [1] which explains permutations with repetion this in general. [Note: We pretty much re-derived the formula for combinations!]
[1] https://brilliant.org/wiki/permutations-with-repetition/
Off the cuff, notice that the diagonal has n+1 intersection points, and a path that never passes through the diagonal gives a forest via the isomorphism with ballot sequences [0]. Any sequence that does pass below the diagonal can be "rotated" into one that doesn't, and so there are probably n+1 paths in each "path class" on average.
Conversely, this would suggest that all paths contained in just one upper or lower triangle of the square can be counted by the Catalan numbers. Indeed, a 2x2 square has just 2 such paths and (2n C n)/(n+1) = 6/3 = 2.
[0]:https://blog.wilsonb.com/posts/2026-02-27-easy-random-trees....
So for counting, you can basically think about it as a list of twenty initially empty spots. You first fill it in with your 10 down steps. The remaining 10 spots will then be the ones for the 10 right steps. So really the only choice you have to make is where to place the 10 down steps.
This question boils down to: in how many different ways can you distribute the 10 down steps over the 20 empty spots? That's 20 choose 10.
needed to justify viewing this as "arranging down vs right movements" as another comment outlines
I managed a guy like that. He was capable of very complex thinking, but he wasn't in love with complexity, he was in love with simplicity. His solutions tended to be of the form, "we can ignore all these things, and just focus on X, and it will provide all the value." He'd notice something and simplify it and the benefit to the company would be measured in multiples of his salary.
Every manager who'd ever directly managed him knew what a treasure he was, but it was often hard for us to convince others of the value of his solutions because they were so simple, and people were convinced that hard problems must have complex solutions. (or else they would have solved them, right?)
He eventually got bored. He retired and joined a seminary.
I did some of that a few times in my life. But I also realised that a large part of the value I brought was not necessarily in coming up with the solution, but in convincing the rest of the company---and in training up enough of the rest of the team to understand and maintain the system.
For example at Goldman, I used an integer linear programming solver to re-shuffle how we assigned compute capacity in different data centres to various departments and how to compute fail-over plans ahead of time.
The actual modelling and implementing barely took any time at all; I used an off-the-shelf open source solver. But I spend multiple weeks teaching the team enough about linear programming so that they can eg change the model when business requirements change.
Give it too long a rest and you have to go back at full blast for weeks on end to hope to ever achieve past performance.
I am very bad at math and have always been in awe of those who can do it well.
I’m building a grid based game and engine, and I have a game replay format which is not video.
I hit a massive wall with compression, trying to compress unit pathing and was trying to solve a similar solution.
Given an NxN grid, and the 4 cardinal directions (NSEW) you can move in, plus an extra action that makes you move 2 cells instead of 1, and considering you can move 4 cells per second…
What’s the smallest worst-case raw compression artefact you can output for 1 player for a 1 minute game?
It’s an extremely fun problem to solve. I tried:
- encoding changes into bits eg using 2 bits for direction
- movement pattern batching (ie batching 2 moves into 3 bits)
- crowd patterns and movement prediction
- treating movement as a “projectile” and deriving intermediate states
And all sorts of other wild crap that I will write up about on game launch
It has become sort of junk food for the brain. Temptations and ads for it everywhere.
But I am reminded of how during my engagement 24 years ago, my future father-in-law raised an issue of being able to determine whether they were getting the full amount of sandpaper on large rolls that they were paying for. I was able to simplify the question a bit to one that treated the rolls as if they were simple concentric rolls of a specified thickness and from there could turn it into the good old Gaussian sum formula times 2π to get the length. The engineers working for the company came up with the same solution, but instead of using n(n-1)/2 they did the summation with multiple rows in excel.
There is no easy way out, you have to rest but you simply can't stop. Your body will rot, your mind too.
PS: song isn't an ode to the grind culture or how to slave away in an office, as lyrics say "you’ve got to work for yourself - Love yourself, feed yourself".
I also tried a weird idea involving popcount, but it didn't scale. My approach was to represent each possible path with 0s (don't turn) and 1s (turn), testing the same number of 0s and 1s. However, even with popcount running in O(1) with hardware support, the total number of possible paths made the idea impractical :)
I feel sad because I had forgotten the simple and intuitive construction of choosing “go down” and “go right” directions. When a person learns more advanced mathematics, it is often the case that the person just applies such advanced mathematics by rote without realizing that a solution can be found with more elementary mathematics and more creativity. It reminded me of the time in middle school before derivatives were taught, when my teacher reminded me that using derivatives to solve a problem would receive no credit.
It is a common experience in mathematical problem solving that the first solution leads to more insight which illuminates a shorter slap-my-forehead solution -- bruised forehead.
Also if you help little kids with homework, you'll see that some problems are quite difficult as well and require you to actually think, even if it's problems for 10 year olds.
Work out the first few cases by hand (1,2,6,20 in our case) and then look up the sequence on "The On-Line Encyclopedia of Integer Sequences" (OEIS):
https://oeis.org/search?q=1%2C2%2C6%2C20&language=english&go...
Well let's actually consider the degenerate cases.
there are 5 places A can go, then 4 left B can go, then 3 left C can go, and so on, until we get 5! = 120 possible permutations of ABCDE. If you replace the B with another A to get now there are only 60 permutations, because half of the original 120 only differed by where the A and the B were relative to one another. By that same logic, has only 30 combinations, and has only 10 (seeing why it's 10 and not 20 is actually the trickiest part imo, it's because there are 3! ways to arrange CDE, but only 1 to arrange CCC).AACCC is isomorphic to RRDDD, which is how we get 10 possible paths to solve the 2*3 grid. We can check this with the binomial theorem: ((2+3) choose 3) = 10.
What's nice about this step by step approach is that it generalizes not just to non-square grids, but to multiple dimensions as well! Imagine trying to get from the top of a 3 by 3 by 3 Rubik's cube to the bottom, how do you do that? Well how many ways are there to rewrite
? The logic above would suggest 9! / (3! 3! 3!) = 1,680 unique paths. And you can just derive it by starting from the degenerate case and figuring out how to slice things up!It's true, if you don't activate this area of your brain often, it's easier to brute force the solution and reach for the easy mechanical calculation. I can feel this when I'm refactoring code. Today, I just have Claude do it for me with a few instructions. Each day, I feel a tiny bit more ignorant about the actual framework's APIs, its abstractions, and its rules. But I still would rather do other things with my time.
As for the problem, luckily for me, this one was easy to derive if you remember factorials, permutations, and remember to account for duplicate patterns
This is high school math.