Remarks..rtf

{\rtf1\ansi\ansicpg1252\deff0\nouicompat{\fonttbl{\f0\fnil\fcharset0 Calibri;}{\f1\fnil\fcharset2 Symbol;}}
{\*\generator Riched20 10.0.19041}\viewkind4\uc1 
\pard\sl276\slmult1\b\f0\fs22\lang9 Overview:\par
\b0\tab The overall methodology here is that the program identifies what I call "cells:" sets of locations, all of which will be represented by a single location in the downsampled output. When the cell is defined, the program iterates through all the locations within it, then finds the mode. This avoids the problem of referring to information-inadequate intermediate\~arrays, because there are no intermediate arrays: a sampling factor of eight (the third phase in each of the examples) simply defines and analyses cells that are eight units in each dimension. This strategy also makes multithreading easy, because no position will ever be read or written more than once per downsampling, so there is no need for precautions against races.\par
\par
\b Efficacy:\par
\b0\tab Testing this sort of thing is difficult, because the scope of possible variables is extremely broad, and real automated testing would require the generation of "correct" outcomes, which itself could be erroneous. However, I can say that the click-and-eyeball testing that I have done has shown a 100% success rate, and I have not encountered any errors in any combination of dimensions and dimension sizes. In fact, this implementation actually goes beyond the requirements, because it can handle dimension sizes that aren't powers of two.\par
\tab I should mention that up until the of this program's development, it actually determined the mean value of each cell, not the mode. I actually kept a branch which still does this. If you, the customer, could be satisfied with downsampling by mean, the performance of that program is much better than the one you see here. \par
\par
\b Performance:\par
\b0\tab Performance is bad. For referencing purposes, I've included the option to turn off multithreading by changing the "staySynchronous" boolean in DownSampler. Performance of the multithreaded implementation\~is overall comparable to single-threaded, but relative performance varies widely. This is after much tinkering with the criteria for forking. I'm simply out of ideas on this matter. I've set up the main method so that you can\~test different arrays fairly easy just by changing the "tests" array. Note that the two thread-counts only refer to unique threads started for the given purpose. So, right now, all the tests show zero CellModer threads, because all that work is being done by pre-existing threads that were started for CornerFinder work. \par
\par
\b Flaws:\b0\par

\pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\fi-360\li720\sl276\slmult1 Testing: as mentioned above, the testing of this program was somewhat ad-hoc. I always had a slight fear that chunks of the output were empty, or that the downsampling itself was done incorrectly. Practical limitations meant that only small parts of one-dimensional and two-dimensional arrays could be checked for correct downsampling.\par
{\pntext\f1\'B7\tab}Parallel structure: The biggest flaw with this implementation\~is definitely the way that parallelism is done, as seen by it's efficacy compared to single-thread. Conceptually, I'm actually pretty pleased with the logic for CornerSeeker forking, but as you can see in the results of test #4, clearly my judgement is lacking here. I can speak to a big flaw in the logic for forking CellModers: when they do fork children, they have to wait for the children. This means that the time for them to move on is the same as if they did it themselves, plus the overhead for at least one thread. (Again, with the current suite of tests, the standard for forking a child CellModer is never met.) I did attempt a solution to this, by adding all the futures into a list and then cycling/sleeping through the list until they were all done, but this caused problems that I was not able to fix.\par
{\pntext\f1\'B7\tab}Recursiveness: this program is far bulkier than I initially guessed it would be. A lot of this comes down to all the recursion needed to deal with arbitrary dimensions. Try as I might, I couldn't come up with an alternative to this, and it always just ate at me that there might be a far simpler core strategy just out of my reach. Does the form of this program make it more or less difficult to understand and comment on? I don't know; I suspect that it will vary depending on the observer. Nonetheless, I think that this is worth bringing up, because a program that is convoluted or opaque to it's programmers is suboptimal.\lang9\par
}