All posts tagged Programming

Ok, so here is another coding question:

Given an input string, determine whether or not the string is composed of only abbreviations from the periodic table of elements.

This actually sounds kind of complex, like the stacking athlete question I answered previously, but it actually has a 2-line solution:

That’s right, given a string in $line, $result with be true if the string is composed solely of element name abbreviations. Simple huh? As for complexity, who knows. I don’t know enough of how regular expressions are computed to guess, but I assume it’s been made to be somewhat efficient.

Of course, additional optimizations can be made, for instance, “J” is not used in an elemental abbreviation, so any line with “J” could be disqualified (of course that requires a linear search of the data first).

Anyway, here’s the full script, in case you want to impress your friends.

Second example problem:

Given an m * n field of trees and open spaces, find out the biggest square house that can be built with no intersection with trees.

For a suboptimal solution, simple solution starts with scanning every space to see if it is open or not (starting in the upper-left). Find the largest possible square starting at the given space, then find the maximum size square possible in the entire area.

Note that each loop has two conditions, the total width/height of the area AND the max value.  This max-value check keeps the loops from searching for open squares that could not possibly be larger than the current largest square (e.g. too close to one edge of the area).

Now, the function itself, starting at the specified location, searches diagonally for trees, stopping at the first and/or nearest tree it encounters.  It does this by first checking the current square for a tree.  If there is no tree it scans downward until it a) finds a tree or b) reaches the edge of the map.  It repeats the process to the right.  It then increments the “top-left” square inward and repeats the process.

The code above has one special optimization.  We first declare a global variable  std::unordered_map<int,int> FoundMax; This unordered (hash) map is keyed on the x,y coordinates of a square, and stores the maximum size of a square found starting at those coordinates.  This way, it we happen to be searching a diagonal sub-set of a previously searched larger square, we will not have to loop further to find the area of that square.  Note that because this searching works diagonally, we could actually use membership in the FoundMax map as an exit condition (or perhaps, in the outer main loop to prevent calling Find2 in the first place).

The complexity of this algorithm is N for the outer-most loop (once for each square).  From each square, we search a maximum of M additional squares (where M < N), making for a worst-case complexity of O(n*m).  This isn’t a valid expression, true, and by investigation we can see that m decreases logarithmically with respect to n, making a true complexity of O(n log(n)).

Ideas for further optimization: For all upper-left squares with the same X value, the maximum distance down is less than the maximum distance of the previous Y value down. We could therefore skip searching for the next downward tree with a lookup of the nearest downward tree from Y-1 (if we were storing that value). The same goes for the nearest tree to the right from the current X for squares starting on the same Y.


So I was recently presented with an example coding exercise as stated below:

Every athlete is characterized by his mass ‘m’ (in kg) and strength ‘s’ (in kg).
You are to find the maximum number of athletes that can form a tower standing one upon another.
An athlete can hold a tower of athletes with total mass equal to his strength or less than his strength.
Input contains the number of athletes n and their parameters.
For example:

m1 s1
m2 s2

mn sn

If mi > mj then si > sj, but athletes with equal masses can be of different strength.
Number of athletes n < 100000. Masses and strengths are positive integers less than 2000000.
For example:
Input #1

3 4
2 2
7 6
4 5

Would yield
Output #1


Working through the Solution

Phase one, figure out how to store the data.  Easy, store it in a linked list, could be a list of tuples/pairs, but I actually created a class to store the weight/strength, because I want to be able to do a complex sort on the data (see below).

Now, the problem description states that if one athlete weights more than another, it will have greater strength as well.  This provides us with one crucial optimization, we know that the strongest athlete will also be the heaviest.  This athlete, therefore, should go on the bottom of the tower.  We could do a linear search for the strongest, but we can also find the strongest after sorting the list, and we’ll want a sorted list for later.  Therefore, using the comparison operators we described above, we can sort the list of athletes, and begin processing as so:

In the above code, we grab the first entry after sorting, which is (by definition) the strongest. Starting with that athlete’s strength as the maximum weight for any tower to be formed. We then pass the array of athletes, the starting point and weight left to our recursive function. The “tot” variable is there for analysis purposes. The function is defined as below.

The analysis of the algorithm is actually contained in the comments above, but I’ll point out some key points here:

  1. The maximum size of the tower (within the current iteration) is limited to the number of athletes left in the list.  If we find a tower equal to the size of the list, we are done.
  2. If the current athlete weighs more than the remaining weight limit, they (and any other athletes of the same mass) cannot fit on the tower.
  3. The first athlete of any weight is also the strongest (thanks to the sorted list).  Therefore, we only need to consider ONE of any athlete with a given weight (e.g. ALL athletes of weight 4 will be able to support a tower of a most the size of the strength of the strongest athlete).

The loop in the above function scans the lists of athletes, to determine the maximum size of a tower each athlete could support, standing on top of the tower as it stands before the function is called.  Therefore, the first time the function is called, it stands each athlete, in sequence, on top of the shoulders of the strongest athlete, and sees how tall the tower can be built.

If the current athlete can fit on the tower at all (based on remaining weight limit), the recursive call then determines the size of the tower that could then stand on the shoulders of the current athlete. Thanks to item 3 above, we must only perform the recursive call once per athlete weight.  This greatly reduces the number of recursive calls.  The return value of the recursive call is compared to the current maximum tower height found previously (and stored if greater than).  The loops then checks that the maximum tower height does not equal the remaining number of athletes.  If it does, we have found the greatest tower height and can return.

The function returns the tallest tower it found that could stand on the shoulders of the previous athlete.  When the recursion returns completely, we have solved the problem. Worse case scenario of this algorithm is actual 2^n, which is terrible.  But this is because every possible combination of towers must be considered.  However, thanks to our end-conditions (the 3 steps above), we can actually reduce actual complexity to a linear (O(n)) complexity.  This is because we really only have to search the list once, excluding “duplicate” athletes (athletes that could not have supported a stronger tower are discounted thanks to step 3).  With step 1 above, we do not need to continue looping once we have found a maximum tower, and can exit.

Anyway, the full source is in my (poorly misspelled) repository here:

Ok, so while creating my Agbar game, I wanted to play around with particles.  I’m think of making the world destroyable, and this would involve individual particles.

So, I created ParticleWorld.  The example is shown in the video below.

In this video, there are 7 sources of particles (in seven different colors).  One source sprouts up from the bottom middle like a fountain, two come up from the corners, two flow down from the corners, one sprouts in the center (almost like a firework), and there is a constant (orange colored) “rain”.

The debug information on the screen show the Processing FPS (60), Drawing FPS (30), the number of particles in each color and total particles (~7400). The final line shows the time it takes to process all 7400 particles (3-4ms running in a single thread on my 5+ year old Athlon X2 5000+, OCed to 3.2GHz).

Each particle maintains a constant, random X velocity (no air resistance, orange pixels have no lateral movement).  The Y velocity is subject to “normal” gravitational acceleration (9.81 pixels/second/second “down”). The rain is populated in a 1:50 ratio (roughly every 50th column gets a pixel each Processing cycle). Each “fountain” gets one new particle/per Processing cycle.

So anyway, I think it’s a pretty reasonable demo.  7400 independent particles updating at least 250 times per second (if the Processing cycle wasn’t locked to 60Hz) isn’t bad.  I could processing roughly 8 times this number of particles without any lag (at 60Hz).  So now all I need to do is figure out how to use this in my Agbar game.

Source is in my repo.