Using the TIC-80 fantasy console simulator on your pi, implement a program that visually displays a graph of the timed results of your various prime algorithms (brute force + optimizations, sieve of eratosthenes) so that one can more clearly see the difference in performance each algorithm offers.

The graph you should produce can be a simple line graph, perhaps a unique color for each algorithm+optimization, with at least 8 different ranges that you run EACH combination through to obtain the time, and plot that result on your graph.

So: the vertical axis would be time, and the horizontal axis would be the upper bound (getting progressively larger the further you travel to the right).

Additionally, the entire class will be participating in documenting and filling out this project page. It is the responsibility of EACH class member to:

• ask copious, clarifying questions (so you can better add content)
• craft a coherent and organized document, with information located under pertinent headings
• explain the fundamentals of the process, conceptual background, algorithmic approach, and you can even suggest particulars related to TIC-80 (certain functions that might prove useful- individual, unrelated snippets to do things like capturing time, or displaying text, etc.)
• to get full credit, each individual that submits must perform no fewer than 4 changes to this document (as viewable from the wiki revision system). Failure to do so will result in documentation penalties being applied.

Since this program is more about comparing times than finding primes, old display methods are out the window; we want to display a graph, not a list of numbers. In doing so, the resulting screen should more or less use its rectangular area to display a Cartesian mapping of upper bound (since the lower bound may always be 2, or some other constant for simplicity) to time taken for each of the 7 (or 9, including optimization redundancies) calculation methods.

A tried and true method of accomplishing this is the common line, which, by changing its color, may be readily used to represent each of those calculation methods' performance. As the times (and potentially bounds, if desired) may vary on an execution by execution bases, however, a problem is encountered: how is it assured that all of the data is presented to the user? If the scale of the graph is constant, sometimes points may attempt to appear beyond its bounds, or, less catastrophically, detail may be surrendered for graphs which do not take advantage of their maximum bounds. That introduces a new (and useful) concept into this program: dynamic scaling.

Dynamic scaling, as it reads, is variability in size based upon some factor. In our case, that factor is the maximum time taken, as well as the maximum bound calculated. From this information we can derive two scaling factors: one for the x dimension, and one for the y. In order to determine what these values are, though, a size of the graph must first be decided on, and for the purposes of this example the maximum dimensions of the TIC80 screen will be used. By dividing the maximum desired pixel dimensions of the desired graph by the maximum potential values for the point coordinates, you obtain a number which, when multiplied by the time taken or bound calculated of a given datapoint, results in that datapoint scaled up or down to the size of the screen.

// Calculate scalers
xScaler = 240 / maximumBound;
yScaler = 136 / maximumTime;

// Now multiply the point coordinates by the scalers.
// This way, if the point coordinates are larger than the resolution, they 
// will be shrunk. Likewise, if the graph would only take up a fraction
// of the screen, the points will be scaled up.
point.x = point.x * xScaler;
point.y = point.y * yScaler;

I'll be looking for the following:

78:pnf3:final tally of results (78/78)
*:pnf3:no errors, program runs without issue in TIC-80 [13/13]
*:pnf3:user can specify lower and upper bounds at runtime [13/13]
*:pnf3:specified algorithms are implemented and functional [26/26]
*:pnf3:timing of process is implemented, functional, shown [13/13]
*:pnf3:project page contributions as per project specifications [13/13]

Additionally:

• Solutions not abiding by SPIRIT of project will be subject to a 25% overall deduction
• Solutions not utilizing descriptive why and how COMMENTS will be subject to a 25% overall deduction
• Solutions not utilizing INDENTATION to promote scope and clarity will be subject to a 25% overall deduction
• Solutions lacking ORGANIZATION and are not easy to read (within 90 char width) are subject to a 25% overall deduction