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...
41–50 of 159 posts
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...
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…
If his monetary value to the company was as said why would any other metric like complexity even remotely matter or need convincing assuming the main goal of the company was to make money. Money would matter even more than the interpersonal stuff in most cases but on top of it even the managers treasured him so there should've been even less of an issue of communicating value. Getting bored is totally understandable…
I mean, we are in the industry where it used to be a standard practice, not so long ago, to deliver daily reports about one's activities while "planking", or throwing a beach ball to another person doing some silly acrobatics...
It should come as no surprise that there's no rigorous assessment protocol for these kinds of things anywhere. Retrospectively, I will admit, that enormous amount of effort and resources are wasted due to bad planning. But it's still not done.
I can imagine that with the field becoming more competitive, eventually, the industry specialists will come together and try to address the problem, but so far and for so long the resources just kept flowing in, the huge waste wasn't really a problem.
me@localhost:~> bc d=1; for(i=21; i 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,…
Just noting that Python natively handles integers larger than the machine word size since version 2.5, so this would have worked in Python as well.
https://www.wilfred.me.uk/blog/2014/10/20/the-fastest-bigint...
...
...
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!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…
40 indices, pick 20. Those are East moves, the rest are South moves.
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…
2n choose n is just: you must move East 20 times and South 20 times. Hence any solution looks like a permutation of 20 Es and 20 Ss. Now, only look at the indices for the Es. There are 20 of them. Out of 40. 40 indices, pick 20. Those are East moves, the rest are South moves.
This is high school math.