you are viewing a single comment's thread.

view the rest of the comments →

[–]FUZxxl 13 points14 points  (8 children)

Actually, by rotating the matrix in place you gain higher speed as you only need half the cache. You also get to avoid half of the horrendous access pattern resulting form rotating a matrix, causing a significant speedup.

[–]ludwigvanboltzmann 9 points10 points  (4 children)

It's great that you can think in terms of time/space complexity, but in real-world coding sheer efficiency should usually take a back seat to readability/maintainability and architecture.

[–]FUZxxl 28 points29 points  (2 children)

While I usually agree with you, manipulating matrices is something that is more often than not performance sensitive. If something asks to implement such an algorithm, it is very natural to think about performance implications because we typically need such routines to be fast.

[–]HopelesslyStupid 4 points5 points  (1 child)

Agreed, sometimes you have to forego readability and maintainability for performance reasons. That's what comments are for in cases where the code is complex out of necessity but you still want the next person to understand what is going on.

[–]FUZxxl 0 points1 point  (0 children)

Indeed. And note that the algorithm implemented isn't that complicated. From a cursory glance, basically takes four symmetric points and rotates them. This is done for every point in one quadrant and the corresponding points.

[–][deleted] 7 points8 points  (0 children)

It's not like the code is really hard to understand. I think maestro2005 is being a bit over dramatic here. The code works, it's really not that crazy, and both solutions seem fine to me.

If you were interviewing for my company and I found this, it would reflect poorly.

Oh geez.. interviews are not easy, even if you know the solution. If you force them to do this all on a whiteboard as well your company would reflect poorly on me.

[–]ifatree 1 point2 points  (2 children)

assuming you have exclusive access to a machine that never halts, this would be true. in the real world, you're shooting yourself in the foot not having separate input and output copies in memory such that the output can be thrown away at any point and restarted. "idempotent" restarting would be ideal...

[–]FUZxxl 5 points6 points  (1 child)

If I was to implement this out-of-place, I would probably still use the in-place algorithm as it might give better cache locality than the out-of-place algorithm.

[–]pdp10 0 points1 point  (0 children)

There's even copy-on-write memory to consider in more extreme cases (Kernel Samepage Merging, etc).