Posted by aleda145 5 days 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
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...
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 (?!?!?!?!)
let ans = 1
for (let i=1; i<21; ++i) {
ans *= (41 - i)
ans /= i
}
The same idea can be trivially tweaked to compute any binomial coefficient without ever storing an integer greater than the final result.After the i-th iteration of the for loop, ans will contain n!/((n-i)!i!) which is exactly \binom{n}{i}, an integer.
Technically "ans" can grow above the final result in my example, but even that could be fixed if one really wants (e.g. i must divide either ans or n-i, you play a bit with divmod to figure out which division you do first.)
https://www.wilfred.me.uk/blog/2014/10/20/the-fastest-bigint...
- Python's native integer handling, which already has no size limit.
- PLUS part of the Decimal module in Python's stdlib: BC's floats are DECIMAL by default, not binary.
- PLUS an implementation of Bessel's J function, while neglecting Bessel's K.
- Some features for base conversion using `ibase` and `obase`. So, I suppose you can output numbers to base 60. [EDIT: Correction from earlier: ibase is allowed to be at most 16, while POSIX allows for the maximum value of obase to be at least 99, which therefore does allow for formatting output to base 60.]
At first glance of the question, I had imagined it to be hard but then I read through the solution and other comments to recognize that I had in fact done such a question previously and I had solved it independently during the class if I remember correctly or such classes of problems.
I also agree with the AI and spreadsheets part of thing for what its worth but I can only tell more when I get into job but I have heard such things from my senior brothers.
I feel like there has to be a right balance of complexity though, and for what its worth I think that there are so many other things that one optimizes later on in life with tangential benefits as well with real knowledge about real life use-cases and edge-cases and so much more! I feel like it would be hard to replace with AI as much as (some) people (mostly Marketing) want it to feel so.
I do hope that people don't atrophy their skills though and to solve some coding questions or make projects perhaps as well without LLM by hand if given/having the time. Not everything probably has to be done by the fastest or the most accelerated way as you wouldn't know the destination as it would be found along the way itself. I suppose just like life, so stay safe and have a nice day.