This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:fall2017:discrete:projects:pnc2 [2017/09/11 15:08] – wedge | haas:fall2017:discrete:projects:pnc2 [2017/09/18 15:58] (current) – [Evaluation Criteria] wedge | ||
---|---|---|---|
Line 174: | Line 174: | ||
* 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/ | ||
+ | |||
+ | As such, the following implementation restrictions are also in place: | ||
+ | |||
+ | * focus on **if()**, **ternary**, | ||
+ | * keep your use of **continue** and **break** statements (especially **break** statements) to a necessary minimum). | ||
+ | * absolutely **NO** other non-structured program flow alteration (jumps, gotos, etc.) | ||
+ | * absolutely **NO** infinite loops (**while(1)**, | ||
+ | * 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). | ||
+ | * 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, **ONE** return statement per function (in the case of **void**, 0 return statements). | ||
+ | * No redundant duplication of code to address different top-level conditions or operational constraints (think quantity vs. range- these can successfully co-exist in the same block of code). | ||
+ | * Never leave an initialized or allocated resource unverified- always do proper error checking (was the file successfully opened? Was the memory successfully allocated? | ||
+ | |||
+ | A common resistance or complaint I get with imposing these is that it may make your solutions more cumbersome or less optimal; that actually may not be an incorrect assertion, but remember: we are interested in the longer-term pursuit of structured thinking and effective problem solving. To foster your ability to think flexibly and differently. We tend to be naturally more averse to going against the grain, but to be an effective programmer/ | ||
+ | |||
+ | I am seeking to make you all better thinkers and programmers, | ||
=====Grabit Integration===== | =====Grabit Integration===== | ||
Line 729: | Line 750: | ||
< | < | ||
- | 312:pnc2:final tally of results (312/312) | + | 390:pnc2:final tally of results (390/390) |
</ | </ | ||
Line 738: | Line 759: | ||
*: | *: | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
- | *: | + | *: |
- | *: | + | *: |
- | *: | + | *: |
- | *: | + | *: |
+ | *: | ||
</ | </ |