haas:fall2020:discrete:projects:pnc0
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| haas:fall2020:discrete:projects:pnc0 [2020/08/22 22:09] – [Displaying the runtime] wedge | haas:fall2020:discrete:projects:pnc0 [2020/09/15 14:13] (current) – [Program Specifications] wedge | ||
|---|---|---|---|
| Line 263: | Line 263: | ||
| * each program is to have no fewer and no more than 2 loops in this prime processing section. | * each program is to have no fewer and no more than 2 loops in this prime processing section. | ||
| * in each program, you are not allowed to use a given loop type (for(), while(), do-while()) more than once! | * in each program, you are not allowed to use a given loop type (for(), while(), do-while()) more than once! | ||
| - | * display identified primes (space-separated) to a file pointer called **primelist** | + | * display identified primes (space-separated) to a file pointer called **stdout** |
| - | * stop your stopwatch immediately following your prime processing loops (and terminating newline display to **primelist**). Calculate the time that has transpired (ending time minus starting time). | + | * stop your stopwatch immediately following your prime processing loops (and terminating newline display to **stdout**). Calculate the time that has transpired (ending time minus starting time). |
| - | * output the processing run-time to the file pointer called **timing** | + | * output the processing run-time to the file pointer called **stderr** |
| * your output **MUST** conform to the example output in the **execution** section below. This is also a test to see how well you can implement to specifications. Basically: | * your output **MUST** conform to the example output in the **execution** section below. This is also a test to see how well you can implement to specifications. Basically: | ||
| * as primes are being displayed, they are space-separated (first prime hugs the left margin), and when all said and done, a newline is issued. | * as primes are being displayed, they are space-separated (first prime hugs the left margin), and when all said and done, a newline is issued. | ||
| - | * the timing information will be displayed in accordance to code I will provide below (see the **timing** section). | + | * the timing information will be displayed in accordance to code I will provide below (see the **Timing** section). |
| + | |||
| + | =====Implementation Restrictions===== | ||
| + | |||
| + | As our goal is not only to explore the more subtle concepts of computing but to promote different methods of thinking (and arriving at solutions seemingly in different ways), one of the themes I have been harping on is the stricter adherence to the structured programming philosophy. It isn't just good enough to be able to crank out a solution if you remain blind to the many nuances of the tools we are using, so we will at times be going out of our way to emphasize focus on certain areas that may see less exposure (or avoidance due to it being less familiar). | ||
| + | |||
| + | As such, the following implementation restrictions are also in place: | ||
| + | |||
| + | * use any **break** or **continue**, | ||
| + | * **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | ||
| + | * absolutely **NO** infinite loops (**while(1)** or the like). | ||
| + | * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it; no telling; no " | ||
| + | * All " | ||
| + | * **NO** logic shunts (ie having an if statement nested inside a loop to bypass an undesirable iteration)- this should be handled by the loop condition! | ||
| + | * at most, only **one** return() statement per function. Error terminations should use **exit()** | ||
| + | |||
| + | Write clean, well-indented, | ||
| =====Grabit Integration===== | =====Grabit Integration===== | ||
| Line 469: | Line 485: | ||
| ====Displaying the runtime==== | ====Displaying the runtime==== | ||
| - | Once we have the starting and ending times, we can display this to the **timing** file pointer. You'll want this line: | + | Once we have the starting and ending times, we can display this to the **stderr** file pointer. You'll want this line: |
| <code c> | <code c> | ||
| Line 650: | Line 666: | ||
| ... | ... | ||
| | | ||
| - | ========================================================================================= | ||
| - | | ||
| ========================================================================================= | ========================================================================================= | ||
| lab46: | lab46: | ||
| Line 675: | Line 689: | ||
| ... | ... | ||
| 2097152 | 2097152 | ||
| - | ========================================================================================= | ||
| - | | ||
| ========================================================================================= | ========================================================================================= | ||
| lab46: | lab46: | ||
| Line 686: | Line 698: | ||
| ====Verification==== | ====Verification==== | ||
| - | I also include a validation check- to ensure your prime programs are actually producing the correct list of prime numbers. If the check is successful, you will see " | + | You will want to verify |
| - | + | ||
| - | ====Full Verification Compliance==== | + | |
| - | There' | + | |
| - | + | ||
| - | < | + | |
| - | lab46: | + | |
| - | ========================================================================================= | + | |
| - | reg regm rego regb | + | |
| - | ========================================================================================= | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | coop: OK OK OK OK OK OK OK OK OK OK | + | |
| - | | + | |
| - | | + | |
| - | noargs: | + | |
| - | | + | |
| - | invqty: | + | |
| - | | + | |
| - | invlow: | + | |
| - | | + | |
| - | ========================================================================================= | + | |
| - | lab46: | + | |
| - | </ | + | |
| - | + | ||
| - | ===verifyall tests=== | + | |
| - | The " | + | |
| - | * **qtynorm**: | + | |
| - | * **./ | + | |
| - | * **qtypart**: | + | |
| - | * **./ | + | |
| - | * **rngnorm**: | + | |
| - | * **./ | + | |
| - | * **rngpart**: | + | |
| - | * **./ | + | |
| - | * **coop**: both qty and upper bounds set (q: 2048, ub: 8192) | + | |
| - | * **./ | + | |
| - | * **coop2**: both qty and upper bounds set (q: 512, ub: 8192) | + | |
| - | * **./ | + | |
| - | * **coop3**: both qty and upper bounds set, offset start (24-max, q: 2048, ub: 8192) | + | |
| - | * **./ | + | |
| - | * **noargs**: | + | |
| - | * **./ | + | |
| - | * **invargs**: | + | |
| - | * **./ | + | |
| - | * **invqty**: invalid value for quantity argument given (invokes error) | + | |
| - | * **./ | + | |
| - | * **invnary**: | + | |
| - | * **./ | + | |
| - | * **invlow**: invalid value given for lower bound (invokes error) | + | |
| - | * **./ | + | |
| - | * **invhigh**: | + | |
| - | * **./ | + | |
| - | + | ||
| - | If you'd actually to see the output | + | |
| - | + | ||
| - | For example, if you wanted to see the intended output of the **invnary** test, that would be found in: | + | |
| - | * **/usr/ | + | In the **data/** directory you will find a **primelist.gz** file which contains the first 295947 primes for your verification needs. |
| - | You could easily run your program with the stated arguments for the test, then use **cat** to display the test results and do a visual comparison. | ||
| ====In general==== | ====In general==== | ||
| Analyze the times you see... do they make sense, especially when comparing the algorithm used and the quantity being processed? These are related to some very important core Computer Science considerations we need to be increasingly mindful of as we design our programs and implement our solutions. Algorithmic complexity and algorithmic efficiency will be common themes in all we do. | Analyze the times you see... do they make sense, especially when comparing the algorithm used and the quantity being processed? These are related to some very important core Computer Science considerations we need to be increasingly mindful of as we design our programs and implement our solutions. Algorithmic complexity and algorithmic efficiency will be common themes in all we do. | ||
| Line 757: | Line 710: | ||
| * Code must compile cleanly (no warnings or errors) | * Code must compile cleanly (no warnings or errors) | ||
| * Output must be correct, and match the form given in the sample output above. | * Output must be correct, and match the form given in the sample output above. | ||
| - | * Code must be nicely and consistently indented | + | * Code must be nicely and consistently indented. |
| * Code must utilize the algorithm(s) presented above: | * Code must utilize the algorithm(s) presented above: | ||
| * **primereg.c** must do the raw, unoptimized brute force method | * **primereg.c** must do the raw, unoptimized brute force method | ||
| Line 824: | Line 777: | ||
| *: | *: | ||
| *: | *: | ||
| - | *: | + | *: |
| *: | *: | ||
| *: | *: | ||
| - | *: | ||
| </ | </ | ||
haas/fall2020/discrete/projects/pnc0.1598134199.txt.gz · Last modified: 2020/08/22 22:09 by wedge
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
