This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2019:discrete:projects:nbm0 [2018/10/02 14:59] – external edit 127.0.0.1 | haas:fall2019:discrete:projects:nbm0 [2019/09/09 13:23] (current) – [base conversion] wedge | ||
---|---|---|---|
Line 9: | Line 9: | ||
To apply your skills in crafting and deploying an algorithm that will enable you to convert a value from a source base to a destination base. | To apply your skills in crafting and deploying an algorithm that will enable you to convert a value from a source base to a destination base. | ||
- | =====base conversion===== | + | =====number bases===== |
Number representation, | Number representation, | ||
Line 33: | Line 33: | ||
* argv[3]: output base (represented from the point of view of base 10) | * argv[3]: output base (represented from the point of view of base 10) | ||
* base can be any from range of 2-36 (inclusive) | * base can be any from range of 2-36 (inclusive) | ||
- | * on invalid base (< 2 or > 36, display an error to STDERR and exit). | + | * on invalid base (< 2 or > 36, display an error to STDERR and exit with non-zero value). |
* converts those values into processable numeric values | * converts those values into processable numeric values | ||
* if input value contains invalid counting digits for base, display an error to STDERR and exit. | * if input value contains invalid counting digits for base, display an error to STDERR and exit. | ||
Line 39: | Line 39: | ||
* displays the output value to STDOUT, followed by a single newline. | * displays the output value to STDOUT, followed by a single newline. | ||
* Make sure your program ONLY displays the converted value to STDOUT- we will use this for output validation purposes. | * Make sure your program ONLY displays the converted value to STDOUT- we will use this for output validation purposes. | ||
- | * program then exits. | + | * program then exits, returning 0 on successful execution. |
+ | ====Restrictions==== | ||
Additional constraints: | Additional constraints: | ||
Line 50: | Line 51: | ||
* you may assume a MAXIMUM quantity of 2^64 (basically what can be stored in an **unsigned long long int**), aka 8 bytes for packed data, up to 64 bytes for per-digit binary values. | * you may assume a MAXIMUM quantity of 2^64 (basically what can be stored in an **unsigned long long int**), aka 8 bytes for packed data, up to 64 bytes for per-digit binary values. | ||
+ | =====Sample Output===== | ||
Sample output is as follows: | Sample output is as follows: | ||
Line 76: | Line 78: | ||
</ | </ | ||
=====Submission===== | =====Submission===== | ||
- | ====Project | + | |
- | To submit this program to me using the **submit** | + | =====Submission===== |
+ | To successfully complete this project, the following criteria must be met: | ||
+ | |||
+ | * Code must compile cleanly (no warnings or errors) | ||
+ | * Use the **-Wall** and **--std=gnu99** flags when compiling (which occurs automatically when using **make**). | ||
+ | * Code must be nicely and consistently indented (you may use the **indent** tool) | ||
+ | * Code must utilize the algorithm/ | ||
+ | * Implementation must be free from stated restrictions above | ||
+ | * Output **must** match the specifications presented above (when given the same inputs) | ||
+ | * Code must be commented | ||
+ | * be sure your comments reflect the **how** and **why** of what you are doing, not merely the **what**. | ||
+ | * Track/ | ||
+ | * Submit a copy of your source code to me by running **make submit** | ||
+ | |||
+ | To submit this program to me using the Makefile tool (**make submit**), run the following: | ||
<cli> | <cli> | ||
- | lab46: | + | lab46: |
+ | removed ‘nbm0’ | ||
+ | removed ‘errors’ | ||
+ | |||
+ | Project backup process commencing | ||
+ | |||
+ | Taking snapshot of current project (nbm0) | ||
+ | Compressing snapshot of nbm0 project archive | ||
+ | Setting secure permissions on nbm0 archive | ||
+ | |||
+ | Project backup process complete | ||
Submitting discrete project " | Submitting discrete project " | ||
- | -> nbm0.c(OK) | + | -> ../nbm0-YYYYMMDD-HH.tar.gz(OK) |
SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
+ | lab46: | ||
</ | </ | ||
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | ||
- | ====Submission | + | =====Evaluation |
- | To be successful in this project, the following criteria must be met: | + | What I will be looking for: |
- | * Project must be submit on time, by the posted deadline. | + | < |
- | * Early submissions will earn 1 bonus point per full day in advance of the deadline. | + | 104:nbm0:final tally of results |
- | * Bonus eligibility requires an honest attempt at performing the project (no blank efforts accepted) | + | *:nbm0:submitted file called nbm0.c [5/5] |
- | * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline. | + | *:nbm0: |
- | * To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday, 50% off on Friday, 75% off on Saturday, and worth 0% once it becomes Sunday. | + | *:nbm0: |
- | * Certain projects may not have a late grace period, and the due date is the absolute end of things. | + | *:nbm0:adequate error checking [13/13] |
- | * all requested functionality must conform to stated requirements | + | *:nbm0:adequate modifications [13/13] |
- | * Output generated must conform to any provided requirements and specifications (be it in syntax or sample output) | + | *:nbm0:commit |
- | * output obviously must also be correct based on input. | + | *:nbm0:clean compilation [13/13] |
- | * Processing must be correct based on input given and output requested | + | *:nbm0: |
- | * Specification details are NOT to be altered. This project will be evaluated according to the specifications laid out in this document. | + | </code> |
- | * Code must compile cleanly. | + | |
- | * Each source file must compile cleanly (worth 3 total points): | + | Additionally: |
- | * 3/3: no compiler warnings, notes or errors. | + | * Solutions |
- | * 2/3: one of warning or note present during compile | + | * Solutions not utilizing descriptive why and how comments will be subject |
- | * 1/3: two of warning or note present during compile | + | * Solutions not utilizing indentation to promote scope and clarity will be subject |
- | * 0/3: compiler errors present (code doesn' | + | * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction |
- | * Code must be nicely and consistently indented (you may use the **indent** tool) | + | |
- | * You are free to use your own coding style, but you must be **consistent** | + | |
- | * Avoid unnecessary blank lines (some are good for readability, | + | |
- | * Indentation will be rated on the following scale (worth 3 total points): | + | |
- | * 3/3: Aesthetically pleasing, pristine indentation, | + | |
- | * 2/3: Mostly consistent indentation, | + | |
- | * 1/3: Some indentation issues, difficult to read | + | |
- | * 0/3: Lack of consistent indentation (didn' | + | |
- | * Code must be commented | + | |
- | * Commenting will be rated on the following scale (worth 3 total points): | + | |
- | * 3/3: Aesthetically pleasing (comments aligned or generally not distracting), | + | |
- | * 2/3: Mostly consistent, some distractions or gaps in comments (not explaining important things) | + | |
- | * 1/3: Light commenting effort, not much time or energy appears to have been put in. | + | |
- | * 0/3: No original comments | + | |
- | * should I deserve nice things, my terminal is usually 90 characters wide. So if you'd like to format your code not to exceed 90 character wide terminals (and avoid line wrapping comments), at least as reasonably as possible, those are two sure-fire ways of making a good impression on me with respect | + | |
- | * Sufficient comments explaining the point of provided logic **MUST** be present | + | |
- | * Code must be appropriately modified | + | |
- | * Appropriate modifications will be rated on the following scale (worth 3 total points): | + | |
- | * 3/3: Complete attention to detail, original-looking implementation | + | |
- | * 2/3: Lacking some details (like variable initializations), | + | |
- | * 1/3: Incomplete implementation (typically lacking some obvious details/does not conform to specifications) | + | |
- | * 0/3: Incomplete implementation to the point of non-functionality (or was not started at all) | + | |
- | * Implementation must be accurate with respect to the spirit/ | + | |
- | * 3/3: Implementation is in line with spirit of project | + | |
- | * 2/3: Some avoidance/ | + | |
- | * 1/3: Generally avoiding the spirit of the project (new, different things, resorting to old and familiar, despite it being against the directions) | + | |
- | * 0/3: entirely avoiding. | + | |
- | * Error checking must be adequately and appropriately performed, according | + | |
- | * 3/3: Full and proper error checking performed for all reasonable cases, including queries for external resources and data. | + | |
- | * 2/3: Enough error checking performed | + | |
- | * 1/3: Minimal error checking, code is fragile (code may not work in full accordance with project requirements) | + | |
- | * 0/3: No error checking (code likely does not work in accordance with project requirements) | + | |
- | * Track/ | + | |
- | * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline. | + |