I like recursive functions tho
I've always hated recursion. It's always seemed like a cutesy programming trick that's not reliable in all conditions.
You could blow the stack in an edge case that you didn't think of. So it should never be a standard pattern. It's only good if you need to rewrite something for optimization and recursion is appropriate. But in many cases recursion is slower.
"Look at what I can do in 5 lines of code!" is for programming contests, not for anything important.
Nah Hanoi was easy stuff, first year. Definitely more traumatizing practice problems.
Yea, get back to me when you get to parallel programming.
Writing kernels for parallel execution with OPENCL gives me flashbacks every time I remember them
Or even just try to understand pthreads.
Tis' not hard, just add some sleeps to make sure other thread reads data before it is destroyed 🌚
I didn't have to program this, thankfully. The code was used as an example of recursion but the explanation was lacking so I ended up writing out each frame by end until I understood it. Took a few pages and a couple of hours.
I am grateful that I learned what I did going through it but I'd rather not do it again.
Fuck all programming puzzles. I refuse them.
True hommies hate them too.
Replacing "Programmers:" with "Program:" is more accurate.
spoiler
Tower of Hanoi is actually easy to write program for. Executing it on the other hand...
It'd be a trick if you didn't already know the answer. Or at least, it would be for me. It's also hard to actually visualise.
I didn't know the answer either, but usually you can compose solution from solutions of smaller problems.
solution(0): There are no disks. Nothing to do. solution(n): Let's see if I can use solution(n-1) here. I'll use solution(n-1) to move all but last disk A->B, just need to rename the pins. Then move the largest disk A->C. Then use solution(n-1) to move disks B->C by renaming the pins. There we go, we have a stack based solution running in exponential time.
It's one of the easiest problem in algorithm design, but running the solution by hand would give you a PTSD.
Is this a hard problem to solve? I've not attempted it yet myself.
I seem to remember this was a problem in Advent of Code one year?
I'm imagining there are plenty of algorithms to solve this already, right? With varying numbers of towers and plates? A general solution for solvable amounts of each? Maybe?
This is not a hard problem once you wrap your head around it. It is the earliest that some programmers learn about recursion which has a lot of pitfalls and can be frustrating at times.
It's an easy problem to solve... eventually - it's more annoying to solve optimally and that's what programmers usually get handed as a play problem within a year or two of starting to tinker.
Hanoi flashbacks
In myuniversity, we used to play with these to find the fastest path in AI (A*, first depth etc)
"You mean I just made a very complicated array-manipulating way of calculating (2^n)-1?"
Lettme introduce you to ackermann's function:
int ack(int m, int n) { if (m == 0) { return n+1; } else if((m > 0) && (n == 0)){ return ack(m-1, 1); } else if((m > 0) && (n > 0)) { return ack(m-1, ack(m, n-1)); } }You won't run out of stackoverflows any time soon.
Towers of Hanoi? I don't think so.
Petah?
Idk what is this puzzle called? What am i missing here (just learning to program)
Tower of Hanoi
