← Back to context

Comment by ufmace

17 hours ago

The circle outlining one seems interesting to me. I definitely didn't read the algorithm ahead of time, and I'm probably not as smart as a revolutionary genius computer scientist, but I thought of 2 basic algorithms in a few minutes.

You could iterate over the degrees 0 to 360, use trig functions to figure out where the point at that angle is, and plot the closest point. Might need to be a bit tricky about the step size, but I bet you could compute a decent guess from the radius using more trig functions. Of course that probably doesn't work if you don't have floating point and trig functions.

You could also split it into four quadrants. Plot each of the top, bottom, right, and left points by direct computation of adding/subtracting the radius, then for each quadrant, you start from the computed point, check 3 specific points in the appropriate direction for which way you're going in that quadrant, plot whichever one is closest to the radius away from the center, then repeat from that plotted point until you reach the computed point for the next quadrant. It would be tedious and repetitive, but should be doable. You could probably also avoid computing square roots by comparing the squares instead. So I guess you'd want something based on that idea to do it fast on 90s hardware.

Your second idea is pretty much the direction the classic solution takes: walk along the curve incrementally, avoid square roots, and use symmetry to fill in the other parts

Your second one is somewhat in the right direction, I think. My guess would be that you split the circle into eights, that keeps the tangent slope between zero and one. Then you can go along one axis from 0 to sin(45°) times the radius and the value along the other axis will always either stay the same or change by one as the derivative is between zero and one. As you move along your primary axis, you generally keep the value along the secondary axis unchanged but you accumulate the error. When the error crosses 0.5, you move one pixel along the secondary axis and adjust the error accordingly. And of course you always draw eight mirrored and rotated pixels. In some way an adaptation of the Bresenham algorithm for drawing lines.

Exactly! I used this question regularly. It wasn’t a gotcha question or even an impossible-without-experience question as the author thinks. It was a show me HOW you think through something question. There are a lot of ways to solve it, from scanline to sin/cos to using the circle equation, but you can _progress_ from naive to advanced solutions, and all solutions above plus the DDA or Bresenham solutions have symmetries (hint: more than four quadrants are symmetrical) that you can use to optimize it. A practiced interviewer can learn a lot about the candidate with this question.

  • I wonder if there's a class of people who managed to get CS degrees but really aren't that good. To them, it might feel more like either you remember the perfect and optimal but complex solution you were taught in a class, or you don't happen to remember it and are completely stuck and can't make any progress at all. I don't think I'd want to hire or work with somebody who can't come up with some sort of solution after thinking through it for a few minutes.

    In fact, coming up with the CS-perfect solution immediately may be a bit of an anti-signal. I want the person who can think their way through to a solution to a problem that's new to them reasonably well. The fact that you happened to have memorized the best algorithm for this and can recite it on command doesn't tell me much useful, because nobody has the perfect algorithm for everything memorized.

    • > I wonder if there's a class of people who managed to get CS degrees but really aren't that good

      This is a horrible over-generalization, but it seems to me that at least for last 10 years or so colleges are creating students who are more like systems integrators (glorified stack overflow cut-and-pasters) than developers who can equally well think for themselves and derive things from scratch.

      I learned to program in the late 70's in the 8-bit home computer era, and developers of my generation had no choice but to write most of everything from scratch, other than implementing a few well known published algorithms. You approached everything from a perspective of "how can I solve this problem?" rather than "what can I find to solve this problem for me?". Additionally due to severe hardware constraints (speed, memory) we had to always be creative and think outside the box - the mentality was that nothing was impossible, just a matter of finding the best solution.

    • It's not necessarily a class of people. It's proficiency vs. mastery. Is some set of people more able to master a subject than another? Sure. Each person has different limits to their potential, of course, but for most things achieving mastery is more a matter of putting the work in over time.

    • A family member took the same calculus class that I did, from the same teacher. They passed, per their own account, only by memorizing the rules. I memorized what I needed to but the concepts clicked intuitively. So sure, some people “get it” and some people just pass a subject like CS.