Thanks :-) Yeah, some of the code is a bit weird, and some of it is probably redundant. I had to adopt a more-or-less trial-and-error approach toward the end, to get the updating of the miniature to work. I find that the graphics part of the .NET API is really weird and needlessly convoluted, and I ended up having to convert back and forth between Image and Bitmap objects a lot to get everything to work.

Yes, you said as much, hence why I mentioned it.

It seems the third panel is a couple steps behind the others (at least until the pixelcounts start to flatten out, at that point the change is too small to make a difference).

Either you're too focused on the code and algorithms, or you already noticed this, but look att he attached images, the click count is for the "update all" button, I expected the third panel to contain the previous state, not the second previous state (since the others also contain the previous state).

Of course, as noted, after it stabilizes the previous and current state are similar enough so as to not make a difference in the pixel count.

"Humor".

Hehe, sorry. It was late and I was tired ;-)
Yeah I noticed that, but due to the difficulties I had in getting the third panel to update at all, once I somehow got it working, I stopped fiddling with it, for fear of breaking it again. Maybe I'll take another look at the code today.

As a programmer, I can tell you that this question is extremely flawed to begin with.

In order to solve a problem correctly (and do a program that depicts the solution), the first thing that you do is that you sit down and determine your exact requirements (ie, what is the problem that you need to solve).

Here, the problem that you are expected to solve unclear at best.

It seems they are trying to depict an example of infinite recursion.

Thing is, you won't ever deal with infinite recursion in RL problems (though you may create theoretical infinite recursion in badly written code which will cause your machine to bail out on your at runtime).

At best, you'll deal with recursion problems that are large enough that your stack will bail on you before the recursion ends (and cause a lovely segmentation fault message to appear on your Linux prompt).

EDIT: I take that back, some problems can go to infinity, especially when you deal with precision.

For example, the computation of a sine as an infinite serie can go to infinity and if you felt inclined to be inefficient with your computing resources, it could be represented by recursion (as any loop can) which would produce a case of infinite recursion.

However, this is moot as your computing resources will always be limited and will force you to stop somewhere in the recursion, either at a point where your computation will be precise enough for your needs or otherwise at a point where you'll just raise your hands and say that the problem is not solvable with today's computers.

Anyways, the point still stands that those infinite recursion pictures are more appropriate to people engaging in philosophy than people solving RL problems.

For the record, I did not choose to do an actual implementation of this because I saw numerous real-life applications of the algorithm involved. I did it because it was geeky and fun. Spoilsport ;-p

You're making this more difficult than it is. Basically, the problem is the same as calculating the periodic payment for an amortizing loan (or whatever it's called in english), with a constant (text, bars, frames etc) and a percentage (panel one with a fraction equal to the area of the circle divided by the area of the image etc). The third panel is recursive for only a handful of iterations (the actual scaling/re-sampling algorithm used will decide if it goes towards a black or a white dot, but it should turn white if it's any good), which means that once you've figured the number of iterations, say five, you can view the problem as having eight panels instead of three. What makes this "trivial" is that there's a more or less direct correlation between changes and effects.

If you want something more challenging, try creating a small binary file with an embedded hash of the entire file.. =P

You're clearly seeing more out of this picture than I am.

The first frame indicates the fraction of the image that is black (or is it just the frame?).

The second frame seems to indicate that if the image was printed, it would consume a certain amount of ink (no metric is given, very sloppy... good to determine the ration of ink used between the frames and little else).

The third frame indicates the dimensions of the portion of the frame that have ink, but doesn't include the text (which makes you wonder if the info given in the second and first frame include the text or not... more sloppiness). It's also seems to portray an infinite recursion of all 3 frames.

I fail to see a question in there.

If a teacher had given me a question like that in an exam (especially in a data structures and algorithm exam that have absolutely nothing to do with image processing), I would have entertained a couple of murderous thoughts involving the teacher in question.

Exams are stressful enough as they are for the students... they are not an appropriate medium for the teacher to say "I'm bored and I need to masturbate my ego" by giving some vague esoteric questions.

If you're a teacher and you're so freaking bored, stop stressing up your students with your stupidity and go write philosophy or something.