This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:spring2016:cprog:projects:pnc0 [2016/02/25 17:54] – [Check Results] wedge | haas:spring2016:cprog:projects:pnc0 [2016/02/27 13:13] (current) – [Program] wedge | ||
---|---|---|---|
Line 123: | Line 123: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | Of particular note: the sieve algorithms take advantage of a increased storage space, where others (like brute force) are predominantly time-based. The sieve is also more detailed... even if you don't decide to implement a sieve, take a look and compare the algorithm to what you've done to see the differences in approaches. | ||
=====Program===== | =====Program===== | ||
It is your task to write 3 separate prime number calculating programs: | It is your task to write 3 separate prime number calculating programs: | ||
- | - primebrute.c: | + | - **primebrute.c**: for your brute force implementation |
- | - primesqrt.c: | + | - **primesqrt.c**: for your square root-optimization of the brute force |
- | - primeopt.c: for your optimized solution, be it basing off the existing ones, or taking a different approach | + | - **primeopt.c**: for your optimized solution, be it basing off the existing ones, or taking a different approach |
Your program should: | Your program should: | ||
Line 136: | Line 139: | ||
* these values should be positive integer values; you can make the assumption that the user will always do the right thing. | * these values should be positive integer values; you can make the assumption that the user will always do the right thing. | ||
* start your stopwatch (see **timing** section below): | * start your stopwatch (see **timing** section below): | ||
- | * perform the correct | + | * perform the algorithm against the value |
* if enabled, display the prime numbers found in the range | * if enabled, display the prime numbers found in the range | ||
* output the processing run-time to STDERR (do this always). | * output the processing run-time to STDERR (do this always). | ||
Line 143: | Line 146: | ||
* the timing information will be displayed in accordance to code I will provide (in the **timing** section). | * the timing information will be displayed in accordance to code I will provide (in the **timing** section). | ||
+ | ====Other considerations==== | ||
+ | All your programs MUST perform the calculations to determine primality- you may not always be printing it out (depending on argv[2]), but work must be done to ensure the value is identified as a prime/ | ||
+ | |||
+ | For example: | ||
+ | |||
+ | < | ||
+ | if (show == 1) | ||
+ | { | ||
+ | work to determine if it is prime | ||
+ | if prime | ||
+ | print number | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | will actually skip the core processing, and you’ll see some amazing runtimes as a result. They may be amazing, but they’re not real, because you’re not actually doing anything. | ||
+ | |||
+ | What you want instead: | ||
+ | |||
+ | < | ||
+ | work to determine if it is prime | ||
+ | if (show == 1) | ||
+ | { | ||
+ | if prime | ||
+ | print number | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | there are many ways to express the above, through compound if statements and other arrangements, | ||
+ | |||
+ | That also isn’t to say you can’t avoid doing a work run if you’re able to determine its non-primality with a simple pretest (even value, factor of 3, etc.), but that’s actually considered more of the core “work”, so it is more than okay (and encouraged in the primeopt). | ||
=====Command-Line Arguments===== | =====Command-Line Arguments===== | ||
To automate our comparisons, | To automate our comparisons, |