c4d7359804452b331cd6b1ea1ecd7b9f8735d978
haas/fall2026/common/projects/gfoX.md
| ... | ... | @@ -0,0 +1,259 @@ |
| 1 | +# PROJECT: GRADE FIGURE-OUTERER (gfoX) |
|
| 2 | + |
|
| 3 | +## OBJECTIVE |
|
| 4 | + |
|
| 5 | +To successfully obtain, input, calculate, and derive your current overall |
|
| 6 | +status in the course through the use of a spreadsheet calculator. |
|
| 7 | + |
|
| 8 | +## BACKGROUND |
|
| 9 | + |
|
| 10 | +For this project, you will be installing the **sc** spreadsheet on your |
|
| 11 | +development system (Raspberry pi or other local UNIX/Linux machine you |
|
| 12 | +are using for class transactions), creating a spreadsheet and using it to |
|
| 13 | +tabulate and compute your current status in the class. |
|
| 14 | + |
|
| 15 | +It is likely available for install via your package management system by |
|
| 16 | +the name of `sc`. |
|
| 17 | + |
|
| 18 | +## SC INSTRUCTIONS |
|
| 19 | + |
|
| 20 | +There are two sources of information you can reference for **sc** |
|
| 21 | +operation: |
|
| 22 | + |
|
| 23 | +### MANUAL PAGE |
|
| 24 | + |
|
| 25 | +With the installation of **sc** the manual page is made available for |
|
| 26 | +viewing ('q' to quit, up/down pageup/pagedown to view): |
|
| 27 | + |
|
| 28 | +``` |
|
| 29 | +yoursystem:~$ man sc |
|
| 30 | +``` |
|
| 31 | + |
|
| 32 | +### SC TUTORIAL |
|
| 33 | + |
|
| 34 | +In the manual page there is given reference to an available **sc** |
|
| 35 | +tutorial, also installed with the **sc** package (tutorial itself tells |
|
| 36 | +you how to exit): |
|
| 37 | + |
|
| 38 | +``` |
|
| 39 | +yoursystem:~$ sc /usr/share/doc/sc/tutorial.sc |
|
| 40 | +``` |
|
| 41 | + |
|
| 42 | +### RUNNING |
|
| 43 | + |
|
| 44 | +To operate `sc`, run it and provide the desired spreadsheet calculator |
|
| 45 | +filename you wish to work on. |
|
| 46 | + |
|
| 47 | +While not a requirement, the convention is to add a `.sc` to the end of |
|
| 48 | +your spreadsheet filename, for example: `gfo0.sc` |
|
| 49 | + |
|
| 50 | +### SAVING |
|
| 51 | + |
|
| 52 | +One can use the **P** command to "Put" the file to the filesystem (ie |
|
| 53 | +saving). |
|
| 54 | + |
|
| 55 | +NOTE: unlike in text editors, the **sc** status line is at the top of the |
|
| 56 | +screen. |
|
| 57 | + |
|
| 58 | +## LOOK UP YOUR STATUS |
|
| 59 | + |
|
| 60 | +Ever since the first projects came due and were evaluated, your results |
|
| 61 | +were accessible to you on lab46 via the **status** command. |
|
| 62 | + |
|
| 63 | +The synopsis for the **status** command is: |
|
| 64 | + |
|
| 65 | +``` |
|
| 66 | +status DESIG [OPTION..] |
|
| 67 | +``` |
|
| 68 | + |
|
| 69 | +Where OPTION is any valid presence and combination of viable options |
|
| 70 | +(**detail** is one, **help** is another). |
|
| 71 | + |
|
| 72 | +The most common usage will probably be (square brackets in this context |
|
| 73 | +denote optionality): |
|
| 74 | + |
|
| 75 | +``` |
|
| 76 | +status DESIG [detail] |
|
| 77 | +``` |
|
| 78 | + |
|
| 79 | +Customize per the desired request. If you do not want the detailed view, |
|
| 80 | +omit the `detail` option. If you desire it, include the `detail` option. |
|
| 81 | + |
|
| 82 | +NOTE: **status** and the data it reads from are only accessible on lab46. |
|
| 83 | + |
|
| 84 | +``` |
|
| 85 | +lab46:~$ status DESIG |
|
| 86 | +``` |
|
| 87 | + |
|
| 88 | +Furthermore, if you were curious about the breakdown of points, you could |
|
| 89 | +also append the 'detail' argument to get an expanded view of information: |
|
| 90 | + |
|
| 91 | +``` |
|
| 92 | +lab46:~$ status DESIG detail |
|
| 93 | +``` |
|
| 94 | + |
|
| 95 | +NOTE: because 'detail' is an optional argument we use the square brackets |
|
| 96 | +to denote optionality. You do not type them, instead, you either type |
|
| 97 | +what is in them, or you do not, depending on desired functionality. |
|
| 98 | + |
|
| 99 | +## CALCULATING YOUR GRADE |
|
| 100 | + |
|
| 101 | +Your grade is calculated from four distinct components, three of which |
|
| 102 | +you regularly encounter each week through the semester, and the final one |
|
| 103 | +at the end. Each is worth a certain amount of overall points, that when |
|
| 104 | +added up equals 104 points. With their individual point values, they are: |
|
| 105 | + |
|
| 106 | + * projects (52 points) |
|
| 107 | + * notes (13 points) |
|
| 108 | + * participation (13 points) |
|
| 109 | + * eoce (26 points) |
|
| 110 | + |
|
| 111 | +Within each category, you tally up two different accumulation of points: |
|
| 112 | + |
|
| 113 | + * all the points YOU got |
|
| 114 | + * all the points POSSIBLE to get |
|
| 115 | + |
|
| 116 | +For example, take this sample participation dataset: |
|
| 117 | + |
|
| 118 | +``` |
|
| 119 | +1:wcp1:final tally of results (1/1) |
|
| 120 | +2:wcp2:final tally of results (2/2) |
|
| 121 | +1:wcp3:final tally of results (1/4) |
|
| 122 | +5:wcp4:final tally of results (5/8) |
|
| 123 | +4:moar:final tally of results (4/0) |
|
| 124 | +``` |
|
| 125 | + |
|
| 126 | +This person got 1+2+1+5 points (and 4 bonus points), for a total of: 9 + |
|
| 127 | +4 = 13 points. |
|
| 128 | + |
|
| 129 | +The total amount of points available (at this point) was 1+2+4+8+0, or: |
|
| 130 | +15 points |
|
| 131 | + |
|
| 132 | +A note on 'bonus' points: in each category, there is the potential for |
|
| 133 | +the accumulation of bonus/extra/moar points. These are added into the |
|
| 134 | +mix, BUT for the purposes of grading, the final tally of YOUR points can |
|
| 135 | +NOT exceed the final tally of total points. |
|
| 136 | + |
|
| 137 | +In this case, the person amassed 13 total points, out of a total of 15 |
|
| 138 | +points: for purposes of grading, for their participation score, it would |
|
| 139 | +be 13/15. Bonus points only apply to the particular category in which |
|
| 140 | +they were earned (they cannot be applied to a different category). |
|
| 141 | + |
|
| 142 | +Continuing this example, the person got 13/15ths of the 13 available |
|
| 143 | +points for that section (participation is worth 13 total points). We |
|
| 144 | +would calculate that "out of 13" result as follows: |
|
| 145 | + |
|
| 146 | +`(13/15)*13` = 11 (so at this point, they'd have 11 out of 13 |
|
| 147 | +participation points) |
|
| 148 | + |
|
| 149 | +Do the same for projects (52) and notes (13). For now, the total possible |
|
| 150 | +grade points you can receive is 78 total points (52+13+13). So that is |
|
| 151 | +what your spreadsheet should reflect. |
|
| 152 | + |
|
| 153 | +Your letter grade is obtained by determining your score (out of 100) and |
|
| 154 | +selecting the letter grade pertaining to that value. |
|
| 155 | + |
|
| 156 | +## SPREADSHEET |
|
| 157 | + |
|
| 158 | +For this project, your task is to make a spreadsheet that, in clearly |
|
| 159 | +readable and organized fashion, plots out your various results on the |
|
| 160 | +different deliverables for the class, ultimately displaying your current |
|
| 161 | +overall grade for the course. |
|
| 162 | + |
|
| 163 | +I want to see each project (identified), along with the points you got, |
|
| 164 | +along with the total points possible for a "dashboard" quick glance, |
|
| 165 | +calculate your project "score" out of 100 (just to give you a feel for |
|
| 166 | +how you did on a particular project). Be sure to: |
|
| 167 | + |
|
| 168 | + * have a category for bonus points you have earned |
|
| 169 | + * have a projects score tally (all your points earned) |
|
| 170 | + * have a projects total tally (all the points possible to earn) |
|
| 171 | + |
|
| 172 | +Calculate your projects "score" out of 100 (just to give you a feel for |
|
| 173 | +how you did on the category overall). |
|
| 174 | + |
|
| 175 | +Calculate your projects "points" (out of 52), and display it under an |
|
| 176 | +identifiable label. |
|
| 177 | + |
|
| 178 | +Do the same for the participation and notes categories as well. |
|
| 179 | + |
|
| 180 | +Add up your category points (52+13+13=78), and have these be near each |
|
| 181 | +other in your spreadsheet. |
|
| 182 | + |
|
| 183 | +Calculate your actual current score for the class (based on a total of 78 |
|
| 184 | +points, that you could then determine against the letter grade ladder |
|
| 185 | +where you fall). |
|
| 186 | + |
|
| 187 | +Do NOTE: the aim and spirit of this project is to use the SPREADSHEET as |
|
| 188 | +the calculator. I want to see embedded equations, NOT pre-calculated |
|
| 189 | +values in your spreadsheet data. I do NOT want to see you being the |
|
| 190 | +calculator, pre-calculating all the values, and just entering them. That |
|
| 191 | +is NOT effective use of the spreadsheet. |
|
| 192 | + |
|
| 193 | +Note that you may have to make your terminal window larger, or just deal |
|
| 194 | +with the need to scroll through the spreadsheet when enough data is |
|
| 195 | +accumulated. If you'd like to continue using this spreadsheet for |
|
| 196 | +additional points accrued in the coming weeks, you may want to plan ahead |
|
| 197 | +and set up your "final results" tally with some space away from the |
|
| 198 | +growing list of results. |
|
| 199 | + |
|
| 200 | +## TIME-SENSITIVE DATA |
|
| 201 | + |
|
| 202 | +As gfoX may be issued multiple times during the semester, each iteration |
|
| 203 | +is to capture the following snapshot of data in its reporting results: |
|
| 204 | + |
|
| 205 | + * gfo0: start of semester through and including week 4 deliverables |
|
| 206 | + * gfo1: start of semester through and including week 8 deliverables |
|
| 207 | + * gfo2: start of semester through and including week 12 deliverables |
|
| 208 | + |
|
| 209 | +You'll notice there is a two-week lag from the end of the sampling window |
|
| 210 | +(gfo0 -> week 4) and when that project is due (gfo0 will be due alongside |
|
| 211 | +pct6/wcp6). |
|
| 212 | + |
|
| 213 | +## EXAMPLE |
|
| 214 | + |
|
| 215 | +Here is a mock-up example spreadsheet that I did, organizing information |
|
| 216 | +in the fashion useful for being informative and pertaining to this |
|
| 217 | +project: |
|
| 218 | + |
|
| 219 | + |
|
| 220 | + |
|
| 221 | +## SUBMISSION |
|
| 222 | + |
|
| 223 | +To successfully complete this project, the following criteria must be |
|
| 224 | +met: |
|
| 225 | + |
|
| 226 | + * Solution must utilize the algorithm/approach presented above |
|
| 227 | + * Output must conform to the specifications presented above |
|
| 228 | + * Submit a copy of your solution to me using the **submit** tool. |
|
| 229 | + |
|
| 230 | +To submit this to me using the **submit** tool, run the following command |
|
| 231 | +at your lab46 prompt: |
|
| 232 | + |
|
| 233 | +``` |
|
| 234 | +lab46:~/src/SEMESTER/DESIG/gfoX$ submit DESIG gfoX gfoX.sc |
|
| 235 | +Submitting DESIG project "gfoX": |
|
| 236 | + -> gfoX.sc(OK) |
|
| 237 | + |
|
| 238 | +SUCCESSFULLY SUBMITTED |
|
| 239 | +``` |
|
| 240 | + |
|
| 241 | +You should get some sort of confirmation indicating successful submission |
|
| 242 | +if all went according to plan. If not, check for typos and or locational |
|
| 243 | +mismatches. |
|
| 244 | + |
|
| 245 | +### RUBRIC |
|
| 246 | + |
|
| 247 | +What I will be looking for: |
|
| 248 | + |
|
| 249 | +``` |
|
| 250 | +52:gfoX:final tally of results (52/52) |
|
| 251 | +*:gfoX:gfoX.sc data points entered as numbers, adequately labelled [13/13] |
|
| 252 | +*:gfoX:gfoX.sc all calculations done as equations in spreadsheet [13/13] |
|
| 253 | +*:gfoX:gfoX.sc calculations reference cells, NOT literal data [13/13] |
|
| 254 | +*:gfoX:gfoX.sc calculations use available spreadsheet functions [13/13] |
|
| 255 | +``` |
|
| 256 | + |
|
| 257 | +Additionally: |
|
| 258 | + * Solutions not abiding by **SPIRIT** of project will be subject to a 25% overall deduction |
|
| 259 | + * Solution output lacking **ORGANIZATION** ior are not easy to read (within 90 char width) are subject to a 25% overall deduction |
haas/fall2026/common/projects/images/gfoX_sample.jpg
| ... | ... | Binary files /dev/null and b/haas/fall2026/common/projects/images/gfoX_sample.jpg differ |
haas/fall2026/common/projects/images/pctX_borrows.jpg
| ... | ... | Binary files /dev/null and b/haas/fall2026/common/projects/images/pctX_borrows.jpg differ |
haas/fall2026/common/projects/ntr0.md
| ... | ... | @@ -0,0 +1,99 @@ |
| 1 | +# PROJECT: GETTING STARTED, PART ONE (ntr0) |
|
| 2 | + |
|
| 3 | +## OBJECTIVE |
|
| 4 | + |
|
| 5 | +To get started in your journey in the course this semester |
|
| 6 | + |
|
| 7 | +## TASK |
|
| 8 | + |
|
| 9 | +By the deadline, please do the following: |
|
| 10 | + |
|
| 11 | + * [SIGN ONTO CLASS DISCORD](#sign-onto-class-discord) |
|
| 12 | + * [IDENTIFY YOURSELF AND CLASSES ON DISCORD](#identify-yourself-and-classes-on-discord) |
|
| 13 | + * [PROVIDE GITHUB ACCOUNT](#provide-github-account) |
|
| 14 | + * [PROVIDE SSH PUBLIC KEY](#provide-ssh-public-key) |
|
| 15 | + |
|
| 16 | +Finally, there is information regarding the [SUBMISSION](#submission) and |
|
| 17 | +evaluation of the project at the tail end of this document. |
|
| 18 | + |
|
| 19 | +### SIGN ONTO CLASS DISCORD |
|
| 20 | + |
|
| 21 | +We will be making use of DISCORD for class communications this semester. |
|
| 22 | + |
|
| 23 | +If you already have an existing or preferred account, feel free to use |
|
| 24 | +that with this class. You will be identifying yourself, as a follow-on |
|
| 25 | +step, so there's no need for a class-specific account. |
|
| 26 | + |
|
| 27 | +Please see [this page](https://support.discord.com/hc/en-us/articles/31676852332439-Discord-Sign-Up-and-Registration-Guide) for information on creating your personal DISCORD account, if you do not already have an account. |
|
| 28 | + |
|
| 29 | +The invite to the DISCORD class server can be found near the top of the |
|
| 30 | +class homepage. |
|
| 31 | + |
|
| 32 | +### IDENTIFY YOURSELF AND CLASSES ON DISCORD |
|
| 33 | + |
|
| 34 | +Once on the class DISCORD server, please identify yourself, along with |
|
| 35 | +the classes you are taking so proper roles can be assigned. |
|
| 36 | + |
|
| 37 | +This will actually fully satisfy your week1 PARTICIPATION requirement for |
|
| 38 | +the class. |
|
| 39 | + |
|
| 40 | +### PROVIDE GITHUB ACCOUNT |
|
| 41 | + |
|
| 42 | +We will be making use of GITHUB this semester in the course. To transact |
|
| 43 | +that, you will need to provide the instructor with your preferred GITHUB |
|
| 44 | +username you will be using in the class this semester. |
|
| 45 | + |
|
| 46 | +You can provide this information via email (`haas@corning-cc.edu`), or |
|
| 47 | +even via DM on DISCORD. |
|
| 48 | + |
|
| 49 | +Once your instructor has your GITHUB account, then the magic can happen. |
|
| 50 | + |
|
| 51 | +If you already have an existing github account, you are free to use that. |
|
| 52 | + |
|
| 53 | +Please see [this page](https://docs.github.com/en/get-started/onboarding/getting-started-with-your-github-account) for information on creating your personal GITHUB account, if you do not already have an account. |
|
| 54 | + |
|
| 55 | +### PROVIDE SSH PUBLIC KEY |
|
| 56 | + |
|
| 57 | +For various class-related activities this semester, we will be accessing |
|
| 58 | +the LAB46 SHELL SYSTEM, a Linux-based command-line environment that will |
|
| 59 | +host various course resources. |
|
| 60 | + |
|
| 61 | +Access to the system is via SSH KEY only, so you will need to provide the |
|
| 62 | +instructor with the SSH PUBLIC KEY(s) you'd like to use to access the |
|
| 63 | +system. |
|
| 64 | + |
|
| 65 | +Additionally, SSH KEY access is a preferred way of interacting with your |
|
| 66 | +GITHUB resources, so the key you use for LAB46 can also be used on |
|
| 67 | +GITHUB. |
|
| 68 | + |
|
| 69 | +You can provide this information via email (`haas@corning-cc.edu`), or |
|
| 70 | +even via DM on DISCORD. |
|
| 71 | + |
|
| 72 | +If you already have an existing SSH PUBLIC KEY, you are free to use that. |
|
| 73 | + |
|
| 74 | +If you already have your SSH PUBLIC KEY installed on LAB46, you may |
|
| 75 | +already be all set in this regard: try logging in. For everyone else, |
|
| 76 | +logging into LAB46 will occur in the follow-up project `ntr1`. |
|
| 77 | + |
|
| 78 | +Please see [this page](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) for information on generating an SSH key. |
|
| 79 | + |
|
| 80 | +NOTE: If you already have an existing KEY access to LAB46, and wish to |
|
| 81 | +add additional KEYS (for additional development systems you find yourself |
|
| 82 | +using), just **append** your new SSH **PUBLIC** KEY to the end of your |
|
| 83 | +`~/.ssh/authorized_keys` file on LAB46. |
|
| 84 | + |
|
| 85 | +## SUBMISSION |
|
| 86 | + |
|
| 87 | +``` |
|
| 88 | +26:ntr0:final tally of results (26/26) |
|
| 89 | +*:ntr0:signed into and are active on the class DISCORD [6/6] |
|
| 90 | +*:ntr0:identified self and state classes on DISCORD [7/7] |
|
| 91 | +*:ntr0:provided instructor preferred GITHUB USERNAME [6/6] |
|
| 92 | +*:ntr0:provided instructor preferred SSH PUBLIC KEY [7/7] |
|
| 93 | +``` |
|
| 94 | + |
|
| 95 | +Additionally: |
|
| 96 | + * Solutions not abiding by spirit of project will be subject to a 25% overall deduction |
|
| 97 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 98 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 99 | + * 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 |
haas/fall2026/common/projects/ntr1.md
| ... | ... | @@ -0,0 +1,262 @@ |
| 1 | +# PROJECT: GETTING STARTED, PART TWO (ntr1) |
|
| 2 | + |
|
| 3 | +## OBJECTIVE |
|
| 4 | + |
|
| 5 | +To continue getting started in your journey in the course this semester. |
|
| 6 | +Upon completion of this project, you should have established access to |
|
| 7 | +the pertinent class resources we will be utilizing all semester. |
|
| 8 | + |
|
| 9 | +## TIME MANAGEMENT |
|
| 10 | + |
|
| 11 | +Please note that while this project has a DEADLINE, it is not intended |
|
| 12 | +for you to crank out all in one sitting, especially at the last minute. |
|
| 13 | + |
|
| 14 | +Some steps may require some interaction, or successful completion and |
|
| 15 | +processing of steps from other, previous projects in order to proceed. |
|
| 16 | + |
|
| 17 | +Be sure to give yourself adequate time and do not run out the clock |
|
| 18 | +thinking everything will be smooth sailing. Technical issues could crop |
|
| 19 | +up at any time. |
|
| 20 | + |
|
| 21 | +## TASK |
|
| 22 | + |
|
| 23 | +By the deadline, please do the following: |
|
| 24 | + |
|
| 25 | + * [READ THE MAGE BOOK](#read-the-mage-book) |
|
| 26 | + * [LOG INTO LAB46 SHELL SYSTEM](#log-into-lab46-shell-system) |
|
| 27 | + * [CREATE PRIVATE REPOSITORY ON GITHUB](#create-private-repository-on-github) |
|
| 28 | + * [ESTABLISH README AND PROVIDE INFO](#establish-readme-and-provide-info) |
|
| 29 | + * [CHECK AND EDIT REPO CONFIG](#check-and-edit-repo-config) |
|
| 30 | + * [INVITE INSTRUCTOR TO REPOSITORY](#invite-instructor-to-repository) |
|
| 31 | + * [CLONE CLASS REPOSITORY ONTO LAB46](#clone-class-repository-onto-lab46) |
|
| 32 | + * [CONTRIBUTE CONTENT TO CLASS REPO](#contribute-content-to-class-repo) |
|
| 33 | + |
|
| 34 | +Finally, there is information regarding the [SUBMISSION](#submission) and |
|
| 35 | +evaluation of the project at the tail end of this document. |
|
| 36 | + |
|
| 37 | +### READ THE MAGE BOOK |
|
| 38 | + |
|
| 39 | +If you are unfamiliar with the `lab46` system, or UNIX systems in |
|
| 40 | +general, please take some time to read the "UNIX FOR THE BEGINNING MAGE" |
|
| 41 | +PDF that is available for download off the course homepage. |
|
| 42 | + |
|
| 43 | +Feel free to ask any questions regarding its content and concepts on the |
|
| 44 | +DISCORD. |
|
| 45 | + |
|
| 46 | +### LOG INTO LAB46 SHELL SYSTEM |
|
| 47 | + |
|
| 48 | +Using your SSH KEY, giving adequate time for the instructor to install it |
|
| 49 | +on your account, SSH or MOSH into your account on the `lab46` shell |
|
| 50 | +system. |
|
| 51 | + |
|
| 52 | +Any issues, please report them to the instructor on DISCORD. |
|
| 53 | + |
|
| 54 | +Your username on `lab46` is the same as your CCC username (minus the |
|
| 55 | +`@corning-cc.edu`). It will be **lowercase**. The system is **CaSe |
|
| 56 | +SeNsItIvE**, so assume lowercase unless otherwise indicated. |
|
| 57 | + |
|
| 58 | +The hostname for `lab46` is: `lab46.g7n.org` |
|
| 59 | + |
|
| 60 | +To SSH into `lab46` with your username: `ssh user@lab46.g7n.org` |
|
| 61 | + |
|
| 62 | +To MOSH into `lab46` with your username: `mosh user@lab46.g7n.org` |
|
| 63 | + |
|
| 64 | +What is the difference between **SSH** and **MOSH**? While they both |
|
| 65 | +provide a secure, encrypted connection between your local system and the |
|
| 66 | +remove server (`lab46`), **MOSH** is engineered to handle less reliable |
|
| 67 | +connections. If you find your **SSH** connections choppy and freezing up |
|
| 68 | +due to questionable internet, consider trying out **MOSH**, which may |
|
| 69 | +make your connection experience more tolerable. |
|
| 70 | + |
|
| 71 | +NOTE: while most modern systems will have an SSH CLIENT installed, you |
|
| 72 | +are not guaranteed to have a MOSH CLIENT installed. Feel free to install |
|
| 73 | +one if you wish. |
|
| 74 | + |
|
| 75 | +### CREATE PRIVATE REPOSITORY ON GITHUB |
|
| 76 | + |
|
| 77 | +On GITHUB, under the account your provided to the instructor, create a |
|
| 78 | +new **private** repository by the name of the current SEMESTER. |
|
| 79 | + |
|
| 80 | +Please see [this page](https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-new-repository) for information on creating a new repository on github. |
|
| 81 | + |
|
| 82 | +NOTE: the suggested name for your repository should be the name of the |
|
| 83 | +current SEMESTER. For example, if the semester is `spring2026`, that |
|
| 84 | +would be an ideal name for your new repository. |
|
| 85 | + |
|
| 86 | +If you are taking multiple classes by the same instructor, you will be |
|
| 87 | +using this same repository for those other classes. |
|
| 88 | + |
|
| 89 | +It is suggested you create subdirectories at the base level of this |
|
| 90 | +repository, one for each class you are taking. You may name them after |
|
| 91 | +the course DESIGs to facilitate navigation. |
|
| 92 | + |
|
| 93 | +| DESIG | COURSE | |
|
| 94 | +| --------- | -------------------------------- | |
|
| 95 | +| `cprog` | CSCS1320 C/C++ Programming | |
|
| 96 | +| `unix` | CSCS1730 UNIX/Linux Fundamentals | |
|
| 97 | +| `comporg` | CSCS2650 Computer Organization | |
|
| 98 | +| `sysprog` | CSCS2730 System Programming | |
|
| 99 | + |
|
| 100 | +You can use the `mkdir` command to create new directories. And use the |
|
| 101 | +`ls` command to list them. |
|
| 102 | + |
|
| 103 | +To reduce confusion, please place all content that may be evaluated in |
|
| 104 | +the default **main** branch of your repository. |
|
| 105 | + |
|
| 106 | +Please do clone a copy of your SEMESTER repo onto lab46, it will |
|
| 107 | +facilitate matters when it comes to transacting project resources. |
|
| 108 | + |
|
| 109 | +### ESTABLISH README AND PROVIDE INFO |
|
| 110 | + |
|
| 111 | +In your newly created repository on GITHUB, create a `README.md` file and |
|
| 112 | +in it, state the purpose of the repository. Feel free to document |
|
| 113 | +additional information pertinent for better understanding or navigating |
|
| 114 | +the repository. |
|
| 115 | + |
|
| 116 | +Also in your `README.md`, include an `ABOUT ME` type of section that |
|
| 117 | +provides at least the following information: |
|
| 118 | + |
|
| 119 | + * name or preferred nickname |
|
| 120 | + * program of study you are matriculated in at CCC (CS, Cyber, IT, etc.) |
|
| 121 | + * any other information you'd like to share (preferred email, etc.) |
|
| 122 | + |
|
| 123 | +An example `README.md` might contain (replace `SEMESTER` with the actual |
|
| 124 | +semester, `DESIG#` with specific course DESIG): |
|
| 125 | + |
|
| 126 | +``` |
|
| 127 | +# SEMESTER repository for coursework at SUNY CCC |
|
| 128 | + |
|
| 129 | +This is a repository for the SEMESTER semester, hosting individual |
|
| 130 | +coursework for my various courses. |
|
| 131 | + |
|
| 132 | +Content is categorized by course DESIG, further arranged by individual |
|
| 133 | +project and exploration name. |
|
| 134 | + |
|
| 135 | +## ABOUT ME |
|
| 136 | + |
|
| 137 | +Hello, I am NAME. I am a student enrolled in the PROGRAM program at SUNY |
|
| 138 | +Corning Community College. |
|
| 139 | + |
|
| 140 | +Include any preferred nicknames or other pertinent information you'd like |
|
| 141 | +to share. |
|
| 142 | + |
|
| 143 | +## DESIG1 |
|
| 144 | + |
|
| 145 | +This is where content generated during my explorations of DESIG1 will be stored. |
|
| 146 | + |
|
| 147 | +## DESIG2 |
|
| 148 | + |
|
| 149 | +This is where content generated during my explorations of DESIG2 will be stored. |
|
| 150 | + |
|
| 151 | +``` |
|
| 152 | + |
|
| 153 | +Be sure to **add**, **commit**, and **push** this to your repository. And |
|
| 154 | +synchronize any of your clones of this repository by doing a **pull**. |
|
| 155 | + |
|
| 156 | +### CHECK AND EDIT REPO CONFIG |
|
| 157 | + |
|
| 158 | +To ensure consistent tracking of commits for class evaluation purposes, |
|
| 159 | +on each system that you `clone` your SEMESTER repository on, check the |
|
| 160 | +repository config to make sure your name and e-mail are set to |
|
| 161 | +recognized, sane values (using LAB46 as an example): |
|
| 162 | + |
|
| 163 | +``` |
|
| 164 | +user@lab46:~/src/spring2026$ git config -l |
|
| 165 | +user.name=Firstname Lastname |
|
| 166 | +user.email=user@corning-cc.edu |
|
| 167 | +... |
|
| 168 | +``` |
|
| 169 | + |
|
| 170 | +Make sure your name is properly set, and that your email is set. |
|
| 171 | + |
|
| 172 | +**PLEASE** use your actual name (first/nickname and last name), so that |
|
| 173 | +it is clear it is you making commits to repositories. |
|
| 174 | + |
|
| 175 | +If you choose to use an e-mail address that is not clearly indicative of |
|
| 176 | +who you are, please notify your instructor of your chosen e-mail address |
|
| 177 | +so your commits are properly evaluated and credited to you. |
|
| 178 | + |
|
| 179 | +Please see [this page](https://docs.github.com/en/get-started/git-basics/setting-your-username-in-git?platform=linux) for information on configuring your name in git. |
|
| 180 | + |
|
| 181 | +And then, see [this page](https://docs.github.com/en/account-and-profile/how-tos/email-preferences/setting-your-commit-email-address) for information on configuring your e-mail address in git. |
|
| 182 | + |
|
| 183 | +Unless you have experience and established preferences, set these values |
|
| 184 | +in a **global** fashion (on each system you're using git on) for |
|
| 185 | +convenience and peace of mind. |
|
| 186 | + |
|
| 187 | +### INVITE INSTRUCTOR TO REPOSITORY |
|
| 188 | + |
|
| 189 | +On GITHUB, invite the instructor to be a contributor to this private |
|
| 190 | +repo. |
|
| 191 | + |
|
| 192 | +Please see [this page](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/repository-access-and-collaboration/inviting-collaborators-to-a-personal-repository) for information on inviting collaborators to a repository on GITHUB. |
|
| 193 | + |
|
| 194 | +If you'd like them to potentially offer assistance, you can give your |
|
| 195 | +instructor read/write access. But at a minimum, they must be able to |
|
| 196 | +CLONE and READ the repository. |
|
| 197 | + |
|
| 198 | +The instructor's GITHUB account is: `wedge1020` |
|
| 199 | + |
|
| 200 | +### CLONE CLASS REPOSITORY ONTO LAB46 |
|
| 201 | + |
|
| 202 | +A GITHUB repository has been created for use in collaborative class |
|
| 203 | +activities (specific to the class). Please clone it onto `lab46` and your |
|
| 204 | +various work systems. |
|
| 205 | + |
|
| 206 | +For `lab46`, please clone it under your `~/src/` directory in the base of |
|
| 207 | +your home directory. |
|
| 208 | + |
|
| 209 | +You are free to rename the directory the cloned repository resides in. |
|
| 210 | + |
|
| 211 | +You are free to clone it on your other development systems as desired, to |
|
| 212 | +facilitate your workflow. |
|
| 213 | + |
|
| 214 | +Since you will be a contributor to the repository, expect an invitation |
|
| 215 | +to join the repository once the instructor has successfully received and |
|
| 216 | +processed your GITHUB username, and you've installed your SSH PUBLIC KEY |
|
| 217 | +into your GITHUB account. |
|
| 218 | + |
|
| 219 | +As invitations last for around 7 days, please don't delay in responding |
|
| 220 | +(in the affirmative) to joining the repository. |
|
| 221 | + |
|
| 222 | +### CONTRIBUTE CONTENT TO CLASS REPO |
|
| 223 | + |
|
| 224 | +The class repository will be used for various collaborative class |
|
| 225 | +activities, potentially involving: |
|
| 226 | + |
|
| 227 | + * recording, organizing, presenting of class notes |
|
| 228 | + * performing some prescribed documentation activity |
|
| 229 | + * working on a collaborative class project |
|
| 230 | + |
|
| 231 | +The aim is for your regular (weekly) interaction in this repository to |
|
| 232 | +(in part), count towards the JOURNAL component of your grade. |
|
| 233 | + |
|
| 234 | +A suggested `ntr1`-level contribution would be contributing to the course |
|
| 235 | +notes: ensure it contains the relevant information for getting started, |
|
| 236 | +as experienced across both `ntr0` and `ntr1`, along with any additional |
|
| 237 | +informational tidbits you've encountered/discovered. |
|
| 238 | + |
|
| 239 | +We may want to have a FREQUENTLY ASKED QUESTIONS section as well, where |
|
| 240 | +class members can pose questions, to have others respond to them. |
|
| 241 | + |
|
| 242 | +## SUBMISSION |
|
| 243 | + |
|
| 244 | +Once again, no manual submission is needed: evaluation is able to be |
|
| 245 | +performed if you have successfully completed the needed steps described |
|
| 246 | +above. |
|
| 247 | + |
|
| 248 | +``` |
|
| 249 | +52:ntr1:final tally of results (52/52) |
|
| 250 | +*:ntr1:SSH or MOSH login into lab46 with your SSH KEY [13/13] |
|
| 251 | +*:ntr1:created private SEMESTER repository on GITHUB [6/6] |
|
| 252 | +*:ntr1:establish README and provide requested info [7/7] |
|
| 253 | +*:ntr1:invited instructor to your private SEMESTER repo [13/13] |
|
| 254 | +*:ntr1:cloned class repository from GITHUB on lab46 [6/6] |
|
| 255 | +*:ntr1:contribute content to class repository [7/7] |
|
| 256 | +``` |
|
| 257 | + |
|
| 258 | +Additionally: |
|
| 259 | + * Solutions not abiding by spirit of project will be subject to a 25% overall deduction |
|
| 260 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 261 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 262 | + * 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 |
haas/fall2026/common/projects/pctX.md
| ... | ... | @@ -0,0 +1,1804 @@ |
| 1 | +# PROJECT: PRACTICING CRITICAL THINKING (PCTX) |
|
| 2 | + |
|
| 3 | +# TABLE OF CONTENTS |
|
| 4 | + |
|
| 5 | + * [OBJECTIVE](#objective) |
|
| 6 | + * [BACKGROUND](#background) |
|
| 7 | + * [INVESTIGATION/LOGIC METHODS](#investigation/logic-methods) |
|
| 8 | + * [MATH PREPARATION](#math-preparation) |
|
| 9 | + * [LONG DIVISION](#long-division) |
|
| 10 | + * [LETTER DIVISION: AN EXAMPLE](#letter-division-an-example) |
|
| 11 | + * [FINDING K (AND J AND L AND O AS WELL)](#finding-k) |
|
| 12 | + * [FINDING OUR ZERO VALUE](#finding-our-zero-value) |
|
| 13 | + * [FINDING V AND G](#finding-v-and-g) |
|
| 14 | + * [FINDING M AND DISCOVERING P](#finding-m-and-discovering-p) |
|
| 15 | + * [GETTING STARTED](#getting-started) |
|
| 16 | + * [PROCESS](#process) |
|
| 17 | + * [A NOTE ON NUMBER BASES](#a-note-on-number-bases) |
|
| 18 | + * [YOUR SUBMISSION](#your-submission) |
|
| 19 | + * [SUBMISSION FOR REGULAR LETTER DIVISION](#submission-for-regular-letter-division) |
|
| 20 | + * [SUBMISSION FOR SOLVE4 LETTER DIVISION](#submission-for-solve4-letter-division) |
|
| 21 | + * [PUZZLE KEY](#puzzle-key) |
|
| 22 | + * [PUZZLE SOLUTION](#puzzle-solution) |
|
| 23 | + * [VERIFICATION](#verification) |
|
| 24 | + * [REGULAR PUZZLE](#regular-puzzle) |
|
| 25 | + * [EXAMPLE FOR REGULAR PUZZLE](#example-for-regular-puzzle) |
|
| 26 | + * [SOLVE4 PUZZLE](#solve4-puzzle) |
|
| 27 | + * [WALKTHROUGH VIDEOS](#walkthrough-videos) |
|
| 28 | + * [STRATEGIES](#strategies) |
|
| 29 | + * [LEFT EDGE](#left-edge) |
|
| 30 | + * [DETERMINE BORROWS AND TAKES](#determine-borrows-and-takes) |
|
| 31 | + * [TOP IS KNOWN GREATER THAN](#top-is-known-greater-than) |
|
| 32 | + * [TOP IS KNOWN LESS THAN](#top-is-known-less-than) |
|
| 33 | + * [RIGHT EDGE](#right-edge) |
|
| 34 | + * [LOOK FOR ZERO AND GREATEST SYMBOL CANDIDATES](#look-for-zero-and-greatest-symbol-candidates) |
|
| 35 | + * [PROCESS OF ELIMINATION](#process-of-elimination) |
|
| 36 | + * [DOUBLING](#doubling) |
|
| 37 | + * [NEXT-TO HINTS](#next-to-hints) |
|
| 38 | + * [MORE NEXT-TO HINTS](#more-next-to-hints) |
|
| 39 | + * [SUBTRACT BY GREATEST DIGIT, GET INCREMENT](#subtract-by-greatest-digit,-get-increment) |
|
| 40 | + * [SUBTRACT BY KNOWN OFFSET FROM GREATEST DIGIT, GET OFFSET INCREMENT](#subtract-by-known-offset-from-greatest-digit,-get-offset-increment) |
|
| 41 | + * [DIVISOR/MULTIPLICATION RELATIONS](#divisor/multiplication-relations) |
|
| 42 | + * [INVERTED SUBTRACTION PAIRS](#inverted-subtraction-pairs) |
|
| 43 | + * [INVERTED SUBTRACTION RELATIONAL PAIRS](#inverted-subtraction-relational-pairs) |
|
| 44 | + * [SINGLE-LETTER SUBTRAHEND DETERMINATION](#single-letter-subtrahend-determination) |
|
| 45 | + * [CHECKING YOUR RESULTS](#checking-your-results) |
|
| 46 | + * [SUBMISSION](#submission) |
|
| 47 | + |
|
| 48 | +## OBJECTIVE |
|
| 49 | + |
|
| 50 | +To cultivate your problem solving, critical thinking, analytical, and |
|
| 51 | +observation skills. |
|
| 52 | + |
|
| 53 | +The aim here is on observation, analysis, and documentation. You are |
|
| 54 | +solving and documenting a problem by hand, thinking your way through to |
|
| 55 | +solution, NOT copying something, NOR writing any sort of program. |
|
| 56 | + |
|
| 57 | +## BACKGROUND |
|
| 58 | + |
|
| 59 | +The true nature of problem solving frequently involves critical thinking, |
|
| 60 | +analytical, and observation skills. Where problems are not solved by |
|
| 61 | +memorizing some pre-defined set of answers and regurgitating them |
|
| 62 | +mindlessly, but in crafting an elaborate solution from subtle cues and |
|
| 63 | +tested, experimental realizations. |
|
| 64 | + |
|
| 65 | +This project puts you in contact with such endeavours. The better |
|
| 66 | +acquainted you become with these skills, the more adept you will become |
|
| 67 | +at a wide-array of tasks and activities. |
|
| 68 | + |
|
| 69 | +### INVESTIGATION/LOGIC METHODS |
|
| 70 | + |
|
| 71 | +These problems will make use of investigative and logical processes to |
|
| 72 | +allow us to experiment and ascertain the identity of the various letters. |
|
| 73 | +This is often done through: |
|
| 74 | + |
|
| 75 | + * observation |
|
| 76 | + * seeing patterns |
|
| 77 | + * analysis |
|
| 78 | + * investigation |
|
| 79 | + * [abduction](https://en.wikipedia.org/wiki/Abductive_reasoning) |
|
| 80 | + * [induction](https://www.analyzemath.com/math_induction/mathematical_induction.html) |
|
| 81 | + * [deduction](http://mathcentral.uregina.ca/QQ/database/QQ.09.99/pax1.html) |
|
| 82 | + |
|
| 83 | +### MATH PREPARATION |
|
| 84 | + |
|
| 85 | +If you find yourself struggling with the concepts of the underlying math: |
|
| 86 | + |
|
| 87 | + * [Basic Math](https://www.ipracticemath.com/learn/basicmath) |
|
| 88 | + * [Long Division](https://www.mathsisfun.com/long_division.html) |
|
| 89 | + |
|
| 90 | +The pctX problems are just your standard “long division with |
|
| 91 | +remainder” style problems, only given to you worked out, with the |
|
| 92 | +numbers replaced with letters, so instead of going at it beginning to |
|
| 93 | +end, we investigate it end to start. |
|
| 94 | + |
|
| 95 | +### LONG DIVISION |
|
| 96 | + |
|
| 97 | +A letter division is a category of logic problem where you would take an |
|
| 98 | +ordinary math equation (in long form), and substitute all the numbers for |
|
| 99 | +letters, thereby in a direct sense masking the numeric values present |
|
| 100 | +that correctly enable the problem to work from start to completion. It is |
|
| 101 | +your task, through exploring, experimenting, and playing, to ascertain |
|
| 102 | +the numeric value of each letter (as many as 10, one for each numeric |
|
| 103 | +value 0-9). |
|
| 104 | + |
|
| 105 | +We will be focusing on long division, something you learned (and perhaps |
|
| 106 | +last experienced, before becoming mindlessly addicted to pressing buttons |
|
| 107 | +on a calculator), in grade school. It entails a whole number (integer) |
|
| 108 | +division, involving aspects addition (through borrowing), and subtraction |
|
| 109 | +(primarily) to arrive at a quotient and a remainder, and if applicable: |
|
| 110 | +multiplication. |
|
| 111 | + |
|
| 112 | +There is also a logical/relational aspect to these puzzles, which may |
|
| 113 | +well be less familiar territory to some. But so incredibly important when |
|
| 114 | +exploring a process and communicating such notions to the computer. |
|
| 115 | + |
|
| 116 | +Division is unique in that it produces two 'answers', each serving |
|
| 117 | +particular uses in various applications. |
|
| 118 | + |
|
| 119 | +Here is an example (using numbers): |
|
| 120 | + |
|
| 121 | +First up, we're going to divide 87654321 (the dividend) by 1224 (the |
|
| 122 | +divisor). Commonly, especially if punching into a calculator, we might |
|
| 123 | +express that equation as: |
|
| 124 | + |
|
| 125 | +``` |
|
| 126 | +87654321/1224 |
|
| 127 | +``` |
|
| 128 | + |
|
| 129 | +Or in a language like C, assigning the quotient to the variable **x** (an |
|
| 130 | +**int**eger): |
|
| 131 | + |
|
| 132 | +``` |
|
| 133 | + x = 87654321 / 1224; |
|
| 134 | +``` |
|
| 135 | + |
|
| 136 | +But, we're not specifically interested in the 'answer' (quotient or |
|
| 137 | +remainder); we are interested in the PROCESS. You know, the stuff the |
|
| 138 | +calculator does for you, which in order to perform this project and |
|
| 139 | +better explore the aspects of critical thinking, we need to take and |
|
| 140 | +encounter every step of the way: |
|
| 141 | + |
|
| 142 | +``` |
|
| 143 | + 71613 |
|
| 144 | + +--------- |
|
| 145 | +1224 | 87654321 |
|
| 146 | + -8568 |
|
| 147 | + ==== |
|
| 148 | + 1974 |
|
| 149 | + -1224 |
|
| 150 | + ==== |
|
| 151 | + 7503 |
|
| 152 | + -7344 |
|
| 153 | + ==== |
|
| 154 | + 1592 |
|
| 155 | + -1224 |
|
| 156 | + ==== |
|
| 157 | + 3681 |
|
| 158 | + -3672 |
|
| 159 | + ==== |
|
| 160 | + 9 |
|
| 161 | +``` |
|
| 162 | + |
|
| 163 | +Here we obtain the results (focusing on the quotient up top; as the |
|
| 164 | +remainder quite literally is what remains once we're done- we're |
|
| 165 | +specifically NOT delving into decimal points, but instead doing integer |
|
| 166 | +division, which as previously stated has MANY important applications in |
|
| 167 | +computing) through a step by step process of seeing how many times our |
|
| 168 | +divisor (1224) best and in the smallest fashion fits into some current |
|
| 169 | +value of the dividend (or intermediate result thereof). |
|
| 170 | + |
|
| 171 | +For instance, seeking the smallest "best fit" of 1224 into 87654321, we |
|
| 172 | +find that 1224 fits best SEVEN times (1224 * 7 = 8568, which is the |
|
| 173 | +CLOSEST we can get to 8765... 1224 * 8 = 9792, which would be too big |
|
| 174 | +(and way too small for 87654). Clearly, we are seeking those values that |
|
| 175 | +best fit within a multiple of 0-9, staying away from double digits of |
|
| 176 | +multiplication (although, we COULD do it that way and still arrive at the |
|
| 177 | +same end result). |
|
| 178 | + |
|
| 179 | +So: 8765-8568 = 197. |
|
| 180 | + |
|
| 181 | +We have our first result, yet: there's still values in the dividend |
|
| 182 | +(87654321) remaining to process, specifically the 4321, so we take them |
|
| 183 | +one digit at a time. |
|
| 184 | + |
|
| 185 | +The next available, unprocessed digit in 4321 is '4', so we 'drop that |
|
| 186 | +down' and append it to our previous result (197), giving us: 1974. |
|
| 187 | + |
|
| 188 | +We now see how many times (via single digit multiplication), our divisor |
|
| 189 | +(1224) can fit into 1974. As it turns out, just once. |
|
| 190 | + |
|
| 191 | +So: 1974-1224 = 750. |
|
| 192 | + |
|
| 193 | +And we keep repeating the process until there are no more digits from the |
|
| 194 | +dividend to drop down; at which point, we are left with a remainder (in |
|
| 195 | +the above problem, the lone '9' at the very bottom; THAT is the |
|
| 196 | +remainder). |
|
| 197 | + |
|
| 198 | +Clearly it is important to have a handle on and understanding of the |
|
| 199 | +basic long division process before attempting a letter division problem. |
|
| 200 | +So, be sure to try your hand at a few practice problems before |
|
| 201 | +proceeding. |
|
| 202 | + |
|
| 203 | +## LETTER DIVISION AN EXAMPLE |
|
| 204 | + |
|
| 205 | +Following will be a sample letter division problem, and a documented |
|
| 206 | +solution of it, much as you will be doing for this project (and to be |
|
| 207 | +sure: the aim here is not merely to solve it, but to DOCUMENT HOW YOU |
|
| 208 | +SOLVED IT. You might want to keep notes as you go along to save you time |
|
| 209 | +and sanity). |
|
| 210 | + |
|
| 211 | +Here goes: |
|
| 212 | + |
|
| 213 | +``` |
|
| 214 | + GLJK |
|
| 215 | + +--------- |
|
| 216 | + KJKK | GLMBRVLR |
|
| 217 | + -VKOKL |
|
| 218 | + ===== |
|
| 219 | + LJBGV |
|
| 220 | + -OKVKG |
|
| 221 | + ===== |
|
| 222 | + JJGKL |
|
| 223 | + -LKBKV |
|
| 224 | + ===== |
|
| 225 | + KVRMR |
|
| 226 | + -JKRKB |
|
| 227 | + ===== |
|
| 228 | + VKMK |
|
| 229 | + |
|
| 230 | +letters: BGJKLMOPRV |
|
| 231 | +``` |
|
| 232 | + |
|
| 233 | +First off, note how this is NO DIFFERENT from the numeric problem above: |
|
| 234 | +just instead of numbers, which we've associated some concepts with, here |
|
| 235 | +we have letters (each letter maps to a unique number, 0-9). The trick |
|
| 236 | +will be to figure out which letter maps to which number. |
|
| 237 | + |
|
| 238 | +So, let us begin. |
|
| 239 | + |
|
| 240 | +One aim is to obtain the key to the puzzle, the mapping of the letters to |
|
| 241 | +numbers, so I will typically set up an answer key as follows: |
|
| 242 | + |
|
| 243 | +``` |
|
| 244 | +| 0 | | |
|
| 245 | +| 1 | | |
|
| 246 | +| 2 | | |
|
| 247 | +| 3 | | |
|
| 248 | +| 4 | | |
|
| 249 | +| 5 | | |
|
| 250 | +| 6 | | |
|
| 251 | +| 7 | | |
|
| 252 | +| 8 | | |
|
| 253 | +| 9 | | |
|
| 254 | +``` |
|
| 255 | + |
|
| 256 | +Another thing I like to do is set up a more visual representation of what |
|
| 257 | +each letter COULD be. I do so in the following form (I call this a "Range |
|
| 258 | +Table"): |
|
| 259 | + |
|
| 260 | +``` |
|
| 261 | +B = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 262 | +G = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 263 | +J = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 264 | +K = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 265 | +L = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 266 | +M = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 267 | +O = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 268 | +P = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 269 | +R = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 270 | +V = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 271 | +``` |
|
| 272 | + |
|
| 273 | +Then, as I figure things out (either what certain are, but mostly, which |
|
| 274 | +ones they are NOT), I can mark it up accordingly. |
|
| 275 | + |
|
| 276 | +Right from the start, we can already make some important connections; |
|
| 277 | +looking at EACH of the subtractions taking place, in the left-most |
|
| 278 | +position, we see an interesting phenomenon taking place- G-V=0, L-O=0, |
|
| 279 | +J-L=0, and K-J=0. |
|
| 280 | + |
|
| 281 | +Now, since EACH letter is its own unique numeric value, subtracting one |
|
| 282 | +letter from another on its own won't result in a value of 0, but being |
|
| 283 | +borrowed from will. |
|
| 284 | + |
|
| 285 | +That is: 7-6=1, but (7-1)-6=0. THAT is what is going on here. |
|
| 286 | + |
|
| 287 | +So what we can infer from this, is some very important connections: |
|
| 288 | + |
|
| 289 | + * V is one less than G (I'll write it as: V < G) |
|
| 290 | + * O is one less than L (O < L) |
|
| 291 | + * L is one less than J (L < J) |
|
| 292 | + * J is one less than K (J < K) |
|
| 293 | + |
|
| 294 | +Does that make sense? From looking at the puzzle, those four relations |
|
| 295 | +can be made. |
|
| 296 | + |
|
| 297 | +Now, FURTHERMORE, some of those connections are thereby connected. Look |
|
| 298 | +at the 'L' and 'J' connections: |
|
| 299 | + |
|
| 300 | + * O < L, but also: L < J |
|
| 301 | + * L < J, but also: J < K |
|
| 302 | + |
|
| 303 | +That implies a further connection, so we can chain them together: |
|
| 304 | + |
|
| 305 | + * O < L < J < K |
|
| 306 | + |
|
| 307 | +So from that initial observation and connection, we now have two |
|
| 308 | +disconnected relationships: |
|
| 309 | + |
|
| 310 | + * V < G |
|
| 311 | + * O < L < J < K |
|
| 312 | + |
|
| 313 | +From what we've done so far, we do not know where V,G fall in respect to |
|
| 314 | +O,L,J,K. They might be less than, OR greater than. We won't know without |
|
| 315 | +further information. |
|
| 316 | + |
|
| 317 | +Yet, even WITH this information, we can update our letter ranges: |
|
| 318 | + |
|
| 319 | + * since V is less than G, we know V can NOT be 9. |
|
| 320 | + * similarly, G can NOT be 0. |
|
| 321 | + * O cannot be 9, 8, 7, because we know O is 3 less than K. So even though we don't know what K actually is, because K COULD be 9, we know what O, L, and J can NOT be. |
|
| 322 | + * L cannot be 9 or 8 |
|
| 323 | + * J cannot be 9 |
|
| 324 | + * on the other side, K cannot be 0, 1, or 2 |
|
| 325 | + * J cannot be 0 or 1 |
|
| 326 | + * L cannot be 0. |
|
| 327 | + |
|
| 328 | +So, if we update our range chart accordingly: |
|
| 329 | + |
|
| 330 | +``` |
|
| 331 | +B = { 0, 1, 2, 3, 4, 5, 6, 7, 8 } |
|
| 332 | +G = { 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 333 | +J = { 2, 3, 4, 5, 6, 7, 8, } |
|
| 334 | +K = { 3, 4, 5, 6, 7, 8, 9 } |
|
| 335 | +L = { 1, 2, 3, 4, 5, 6, 7, } |
|
| 336 | +M = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 337 | +O = { 0, 1, 2, 3, 4, 5, 6, } |
|
| 338 | +P = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 339 | +R = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 340 | +V = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 341 | +``` |
|
| 342 | + |
|
| 343 | +Moving on, dealing with details of discovering those one-off relations, |
|
| 344 | +that tells us something about the NEXT subtractions: that they borrow |
|
| 345 | +(which means they are LESS THAN the thing being subtracted from them): |
|
| 346 | + |
|
| 347 | + * L is less than K (which we actually know to be 2 less than K), so L - K needs to BORROW |
|
| 348 | + * J is less than K (which we know is 1 less than K), so J - K needs to BORROW |
|
| 349 | + * V is apparently also less than K (which we didn't previously know), so V - K needs to BORROW |
|
| 350 | + * now knowing than V << K, we can connect our other relational fragment in (I use the double '<<' to denote "less than" by an unknown amount, because while we know V is less than K, we don't know by how much). |
|
| 351 | + |
|
| 352 | +So: V < G << O < L < J < K |
|
| 353 | + |
|
| 354 | +This allows us some further whittling of our ranges: |
|
| 355 | + |
|
| 356 | + * V cannot be 9, 8, 7, 6, or 5 |
|
| 357 | + * G cannot be 9, 8, 7, or 6 |
|
| 358 | + * O cannot be 0, or 1 |
|
| 359 | + * L cannot be 0, 1, or 2 |
|
| 360 | + * J cannot be 0, 1, 2, or 3 |
|
| 361 | + * K cannot be 0, 1, 2, 3, or 4 |
|
| 362 | + |
|
| 363 | +``` |
|
| 364 | +B = { 0, 1, 2, 3, 4, 5, 6, 7, 8 } |
|
| 365 | +G = { 1, 2, 3, 4, 5, } |
|
| 366 | +J = { 4, 5, 6, 7, 8, } |
|
| 367 | +K = { 5, 6, 7, 8, 9 } |
|
| 368 | +L = { 3, 4, 5, 6, 7, } |
|
| 369 | +M = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 370 | +O = { 2, 3, 4, 5, 6, } |
|
| 371 | +P = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 372 | +R = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } |
|
| 373 | +V = { 0, 1, 2, 3, 4, } |
|
| 374 | +``` |
|
| 375 | + |
|
| 376 | +Already we can see that V and G are likely lower numbers, and O, L, J, |
|
| 377 | +and K are likely higher numbers. |
|
| 378 | + |
|
| 379 | +What else do we have? Let's keep going: |
|
| 380 | + |
|
| 381 | +We cannot instantly proceed to the next subtraction in as obvious a |
|
| 382 | +progression, as we'll need more information on the various letters |
|
| 383 | +involved. |
|
| 384 | + |
|
| 385 | +### FINDING K |
|
| 386 | + |
|
| 387 | +... and J and L and O as well. |
|
| 388 | + |
|
| 389 | +However, looking at the puzzle, I'm interested in seeing if we can find |
|
| 390 | +any obvious examples of 0. You know, letter minus same letter sort of |
|
| 391 | +things. Because they will typically end up equalling 0 (or 9). |
|
| 392 | + |
|
| 393 | +Why 9? Because of a borrow! |
|
| 394 | + |
|
| 395 | +``` |
|
| 396 | +((5-1)+10)-5 = (4+10)-5 = 14 - 5 = 9 |
|
| 397 | +``` |
|
| 398 | + |
|
| 399 | +... that can be quite revealing too! |
|
| 400 | + |
|
| 401 | +And it would appear we have one wonderful candidate in the bottom-most |
|
| 402 | +subtraction: |
|
| 403 | + |
|
| 404 | +``` |
|
| 405 | + KVRMR |
|
| 406 | + -JKRKB |
|
| 407 | + ===== |
|
| 408 | + VKMK |
|
| 409 | +``` |
|
| 410 | + |
|
| 411 | +Lookie there: R-R = K. |
|
| 412 | + |
|
| 413 | +Usually, that would result in a 0. BUT, we also know that K can NOT be 0 |
|
| 414 | +(looking at our range table above). |
|
| 415 | + |
|
| 416 | +So, that means it is being borrowed from, and it itself has to borrow, so |
|
| 417 | +we now also know that M is less than K: M << K |
|
| 418 | + |
|
| 419 | +And, as indicated above: |
|
| 420 | + |
|
| 421 | +``` |
|
| 422 | +((R-1)+10)-R = 9! |
|
| 423 | +``` |
|
| 424 | + |
|
| 425 | +We now know that K = 9! |
|
| 426 | + |
|
| 427 | +That suddenly reveals a whole lot to us, due to our relational chains |
|
| 428 | +we've built. Let's update: |
|
| 429 | + |
|
| 430 | +``` |
|
| 431 | +| 0 | | |
|
| 432 | +| 1 | | |
|
| 433 | +| 2 | | |
|
| 434 | +| 3 | | |
|
| 435 | +| 4 | | |
|
| 436 | +| 5 | | |
|
| 437 | +| 6 | O | |
|
| 438 | +| 7 | L | |
|
| 439 | +| 8 | J | |
|
| 440 | +| 9 | K | |
|
| 441 | +``` |
|
| 442 | + |
|
| 443 | +Also, with the new introduction of M being less than K: |
|
| 444 | + |
|
| 445 | +``` |
|
| 446 | +B = { 0, 1, 2, 3, 4, 5, } |
|
| 447 | +G = { 1, 2, 3, 4, 5, } |
|
| 448 | +J = { 8 } |
|
| 449 | +K = { 9 } |
|
| 450 | +L = { 7 } |
|
| 451 | +M = { 0, 1, 2, 3, 4, 5, } |
|
| 452 | +O = { 6 } |
|
| 453 | +P = { 0, 1, 2, 3, 4, 5, } |
|
| 454 | +R = { 0, 1, 2, 3, 4, 5, } |
|
| 455 | +V = { 0, 1, 2, 3, 4, } |
|
| 456 | +``` |
|
| 457 | + |
|
| 458 | +And, our relational chains: |
|
| 459 | + |
|
| 460 | + * V < G << O < L < J < K |
|
| 461 | + * M << O < L < J < K |
|
| 462 | + |
|
| 463 | +Because we don't yet know any relation of M compared to V or G, we have |
|
| 464 | +to keep them separate for now. |
|
| 465 | + |
|
| 466 | +We also have a second disqualifier for K being 0... the ones place |
|
| 467 | +subtraction in that bottom-most subtraction: |
|
| 468 | + |
|
| 469 | +``` |
|
| 470 | +R - B = K |
|
| 471 | +``` |
|
| 472 | + |
|
| 473 | +There's nothing further to the right that could borrow from this problem, |
|
| 474 | +so it can only exist in two states: |
|
| 475 | + |
|
| 476 | + * R is greater than B |
|
| 477 | + * R is less than B |
|
| 478 | + |
|
| 479 | +Since we know that K is 9, there's NO OTHER pair of single digit numbers |
|
| 480 | +we can subtract to get 9, which tells us that: |
|
| 481 | + |
|
| 482 | + * R is less than B (R << B) |
|
| 483 | + |
|
| 484 | +Currently both R and B can be 0-5 (although now, B is 1-5, and R is 0-4). |
|
| 485 | +We'd need to find a combination where (R+10)-B is 9: |
|
| 486 | + |
|
| 487 | +``` |
|
| 488 | +| R: 0 | R: 1 | R: 2 | R: 3 | R: 4 | |
|
| 489 | +| (0+10) | (1+10) | (2+10) | (3+10) | (4+10) | |
|
| 490 | +| 10 | 11 | 12 | 13 | 14 | |
|
| 491 | +``` |
|
| 492 | + |
|
| 493 | +And from that, we're subtracting B, which is 1, 2, 3, 4, or 5. The answer |
|
| 494 | +has to be 9. |
|
| 495 | + |
|
| 496 | +So: |
|
| 497 | + |
|
| 498 | +10-1=9, 11-2=9, 12-3=9, 13-4=9, and 14-5=9 |
|
| 499 | + |
|
| 500 | +Hey, look at that... B is one greater than R (not just R << B, BUT: R < |
|
| 501 | +B) |
|
| 502 | + |
|
| 503 | +Our relational chains: |
|
| 504 | + |
|
| 505 | + * V < G << O < L < J < K |
|
| 506 | + * M << O < L < J < K |
|
| 507 | + * R < B << O < L < J < K |
|
| 508 | + |
|
| 509 | +And our range table: |
|
| 510 | + |
|
| 511 | +``` |
|
| 512 | +B = { 1, 2, 3, 4, 5, } |
|
| 513 | +G = { 1, 2, 3, 4, 5, } |
|
| 514 | +J = { 8 } |
|
| 515 | +K = { 9 } |
|
| 516 | +L = { 7 } |
|
| 517 | +M = { 0, 1, 2, 3, 4, 5, } |
|
| 518 | +O = { 6 } |
|
| 519 | +P = { 0, 1, 2, 3, 4, 5, } |
|
| 520 | +R = { 0, 1, 2, 3, 4, } |
|
| 521 | +V = { 0, 1, 2, 3, 4, } |
|
| 522 | +``` |
|
| 523 | + |
|
| 524 | +If you look, the only letter we've not yet directly interacted with yet |
|
| 525 | +is 'P', although we already know enough about it (that it is 0-5, less |
|
| 526 | +than O, L, J, and K). And if you look closely, you'll notice that 'P' |
|
| 527 | +isn't even present in the letter division problem! So its identity will |
|
| 528 | +rely entirely on the proving of the other values. |
|
| 529 | + |
|
| 530 | +Let's continue on: |
|
| 531 | + |
|
| 532 | +M-K=M, BECAUSE we know M << K, AND BECAUSE we know the subtraction to the |
|
| 533 | +right is borrowing from it (because R < B), we have something like this: |
|
| 534 | +(M-1+10)-K=M |
|
| 535 | + |
|
| 536 | +Can't really do much more with it at this point, but it is important to |
|
| 537 | +know to help us identify the borrows needing to happen. |
|
| 538 | + |
|
| 539 | +### FINDING OUR ZERO VALUE |
|
| 540 | + |
|
| 541 | +(R and B) |
|
| 542 | + |
|
| 543 | +Why don't we go ahead and find 0? If you look in the subtraction above |
|
| 544 | +the bottom one, we have another "letter minus same letter" scenario, and |
|
| 545 | +it doesn't equal K! |
|
| 546 | + |
|
| 547 | +``` |
|
| 548 | + JJGKL |
|
| 549 | + -LKBKV |
|
| 550 | + ===== |
|
| 551 | + KVRM |
|
| 552 | +``` |
|
| 553 | + |
|
| 554 | +We KNOW that V << L, so no borrow is happening there. |
|
| 555 | + |
|
| 556 | +Therefore, K-K, or 9-9, equals 0. So R is 0! |
|
| 557 | + |
|
| 558 | +... and B is 1! Because of our identified relationship. |
|
| 559 | + |
|
| 560 | +Updating things! |
|
| 561 | + |
|
| 562 | +``` |
|
| 563 | +| 0 | R | |
|
| 564 | +| 1 | B | |
|
| 565 | +| 2 | | |
|
| 566 | +| 3 | | |
|
| 567 | +| 4 | | |
|
| 568 | +| 5 | | |
|
| 569 | +| 6 | O | |
|
| 570 | +| 7 | L | |
|
| 571 | +| 8 | J | |
|
| 572 | +| 9 | K | |
|
| 573 | +``` |
|
| 574 | + |
|
| 575 | +Also, with the new introduction of M being less than K: |
|
| 576 | + |
|
| 577 | +``` |
|
| 578 | +B = { 1 } |
|
| 579 | +G = { 3, 4, 5, } |
|
| 580 | +J = { 8 } |
|
| 581 | +K = { 9 } |
|
| 582 | +L = { 7 } |
|
| 583 | +M = { 2, 3, 4, 5, } |
|
| 584 | +O = { 6 } |
|
| 585 | +P = { 2, 3, 4, 5, } |
|
| 586 | +R = { 0 } |
|
| 587 | +V = { 2, 3, 4, } |
|
| 588 | +``` |
|
| 589 | + |
|
| 590 | +NOTE: G is NOT 2, because G is greater than V (one greater, in fact), so |
|
| 591 | +we can similarly whittle that off. |
|
| 592 | + |
|
| 593 | +Relational chains can look as follows now: |
|
| 594 | + |
|
| 595 | + * R < B << V < G << O < L < J < K |
|
| 596 | + * R < B << M << O < L < J < K |
|
| 597 | + * R < B << P << O < L < J < K |
|
| 598 | + |
|
| 599 | +Basically just down to V, G, P, and M. |
|
| 600 | + |
|
| 601 | +### FINDING V AND G |
|
| 602 | + |
|
| 603 | +And I think we have the means to find V: notice the second to last |
|
| 604 | +subtraction, the "LKBKV". You know where we get that from? Multiplying |
|
| 605 | +the divisor (KJKK) by J (since it is the third subtraction taking place). |
|
| 606 | + |
|
| 607 | +We KNOW the numeric values of K and J, in fact we know the values of L, |
|
| 608 | +K, and B. The only thing we don't know is 'V', and since V is in the |
|
| 609 | +one's place, that makes things super easy for us. |
|
| 610 | + |
|
| 611 | +KJKK = 9899 |
|
| 612 | +J = 8 |
|
| 613 | + |
|
| 614 | +So: 9899 x 8 = 79192 = LKBKV! |
|
| 615 | + |
|
| 616 | +V is 2! |
|
| 617 | + |
|
| 618 | +Which means, because V < G, that G is 3! |
|
| 619 | + |
|
| 620 | +Updating our records: |
|
| 621 | + |
|
| 622 | +``` |
|
| 623 | +| 0 | R | |
|
| 624 | +| 1 | B | |
|
| 625 | +| 2 | V | |
|
| 626 | +| 3 | G | |
|
| 627 | +| 4 | | |
|
| 628 | +| 5 | | |
|
| 629 | +| 6 | O | |
|
| 630 | +| 7 | L | |
|
| 631 | +| 8 | J | |
|
| 632 | +| 9 | K | |
|
| 633 | +``` |
|
| 634 | + |
|
| 635 | +Also, with the new introduction of M being less than K: |
|
| 636 | + |
|
| 637 | +``` |
|
| 638 | +B = { 1 } |
|
| 639 | +G = { 3 } |
|
| 640 | +J = { 8 } |
|
| 641 | +K = { 9 } |
|
| 642 | +L = { 7 } |
|
| 643 | +M = { 4, 5, } |
|
| 644 | +O = { 6 } |
|
| 645 | +P = { 4, 5, } |
|
| 646 | +R = { 0 } |
|
| 647 | +V = { 2 } |
|
| 648 | +``` |
|
| 649 | + |
|
| 650 | +Relational chains can look as follows now: |
|
| 651 | + |
|
| 652 | + * `R < B < V < G << M << O < L < J < K` |
|
| 653 | + * `R < B < V < G << P << O < L < J < K` |
|
| 654 | + |
|
| 655 | +### FINDING M AND DISCOVERING P |
|
| 656 | + |
|
| 657 | +And then there were 2. We really just need to find M, or P, and we're |
|
| 658 | +done. And since there are no 'P' values in the puzzle, we need to target |
|
| 659 | +M. So let's look for some candidates: |
|
| 660 | + |
|
| 661 | +Hey, how about this: |
|
| 662 | + |
|
| 663 | +``` |
|
| 664 | + JJGKL |
|
| 665 | + -LKBKV |
|
| 666 | + ===== |
|
| 667 | + KVRM |
|
| 668 | +``` |
|
| 669 | + |
|
| 670 | +One's place subtraction: L - V = M. |
|
| 671 | + |
|
| 672 | +We KNOW L (7) is greater than V (2), so no borrow is happening. |
|
| 673 | + |
|
| 674 | +L-V=M |
|
| 675 | +7-2=5 |
|
| 676 | + |
|
| 677 | +M is 5. That means P is 4 by process of elimination. |
|
| 678 | + |
|
| 679 | +Puzzle completed: |
|
| 680 | + |
|
| 681 | +``` |
|
| 682 | +| 0 | R | |
|
| 683 | +| 1 | B | |
|
| 684 | +| 2 | V | |
|
| 685 | +| 3 | G | |
|
| 686 | +| 4 | P | |
|
| 687 | +| 5 | M | |
|
| 688 | +| 6 | O | |
|
| 689 | +| 7 | L | |
|
| 690 | +| 8 | J | |
|
| 691 | +| 9 | K | |
|
| 692 | +``` |
|
| 693 | + |
|
| 694 | +Also, with the new introduction of M being less than K: |
|
| 695 | + |
|
| 696 | +``` |
|
| 697 | +B = { 1 } |
|
| 698 | +G = { 3 } |
|
| 699 | +J = { 8 } |
|
| 700 | +K = { 9 } |
|
| 701 | +L = { 7 } |
|
| 702 | +M = { 5 } |
|
| 703 | +O = { 6 } |
|
| 704 | +P = { 4 } |
|
| 705 | +R = { 0 } |
|
| 706 | +V = { 2 } |
|
| 707 | +``` |
|
| 708 | + |
|
| 709 | +Relational chains can look as follows now: |
|
| 710 | + |
|
| 711 | + * `R < B < V < G < P < M < O < L < J < K` |
|
| 712 | + |
|
| 713 | +I wasn't able to show it as well in text on the wiki, but I also made a |
|
| 714 | +point to mark up each subtraction to show whether a borrow occurred or |
|
| 715 | +not: |
|
| 716 | + |
|
| 717 | + |
|
| 718 | + |
|
| 719 | +To be sure, there are likely MANY, MANY ways to arrive at these |
|
| 720 | +conclusions. What is important is being observant, performing little |
|
| 721 | +experiments, seeing if there can be any insights to have, even if |
|
| 722 | +whittling away knowing what things can NOT be. |
|
| 723 | + |
|
| 724 | +Your performance on this project will be directly tied to being able to |
|
| 725 | +document your process through the puzzle; I have provided this writeup in |
|
| 726 | +order to show you an example of what that process may look like. |
|
| 727 | + |
|
| 728 | +## GETTING STARTED |
|
| 729 | + |
|
| 730 | +In the **pctX/** sub-directory of your class Public Directory, under a |
|
| 731 | +directory by the name of your username, you will find the following |
|
| 732 | +file(s): |
|
| 733 | + |
|
| 734 | + * **puzzle** |
|
| 735 | + * possibly also a file called **table** |
|
| 736 | + * if desired, you can use **worksheet** as a base for your solution file, or for generating text-based representations for using on discord when asking for help. |
|
| 737 | + |
|
| 738 | +Copy this file into your local project directory. For most classes, a |
|
| 739 | +**grabit** is available. For others, you'll have to manually copy the |
|
| 740 | +file on your own. |
|
| 741 | + |
|
| 742 | +There is also a **MANIFEST** file in the parent directory (the **pctX/** |
|
| 743 | +sub-directory), which will contain MD5sums of the various puzzle keys, |
|
| 744 | +provided to help you in verifying your puzzle key. |
|
| 745 | + |
|
| 746 | +For this project, you have to solve, DOCUMENT, AND VERIFY the provided |
|
| 747 | +puzzle in order to be eligible for full credit will be the one contained |
|
| 748 | +in the **puzzle** file. |
|
| 749 | + |
|
| 750 | +To obtain your puzzle, you can utilize the 'grabit' tool on lab46. |
|
| 751 | + |
|
| 752 | +## PROCESS |
|
| 753 | + |
|
| 754 | +Solve, document, and verify the puzzle. |
|
| 755 | + |
|
| 756 | +On your own. |
|
| 757 | + |
|
| 758 | +Seek to discover and explore and understand, NOT to just come up with an |
|
| 759 | +answer. |
|
| 760 | + |
|
| 761 | +It is recommended you do this by hand, ON PAPER. Furthermore, using graph |
|
| 762 | +paper may help in greatly reducing mistakes, as is using two different |
|
| 763 | +coloured writing implements (green, purple; or blue, black)... write up |
|
| 764 | +the puzzle in one colour, then use the other to mark up borrows and the |
|
| 765 | +like. |
|
| 766 | + |
|
| 767 | +## A NOTE ON NUMBER BASES |
|
| 768 | + |
|
| 769 | +Some of the puzzles you may be presented with may be in different number |
|
| 770 | +bases. |
|
| 771 | + |
|
| 772 | +You are likely acclimated to the **base 10** number system, where we have |
|
| 773 | +ten unique counting digits (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) |
|
| 774 | + |
|
| 775 | +Different number bases simply have less or more digits. |
|
| 776 | + |
|
| 777 | +For example, base 8 and 9 both have fewer than ten counting values: |
|
| 778 | + |
|
| 779 | +| base | numbers | |
|
| 780 | +| ---- | ------------------------- | |
|
| 781 | +| 8 | 0, 1, 2, 3, 4, 5, 6, 7 | |
|
| 782 | +| 9 | 0, 1, 2, 3, 4, 5, 6, 7, 8 | |
|
| 783 | + |
|
| 784 | +And then we have bases with MORE counting values than in base 10: |
|
| 785 | + |
|
| 786 | +| base | numbers | |
|
| 787 | +| ---- | ---------------------------------- | |
|
| 788 | +| 11 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A | |
|
| 789 | +| 12 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B | |
|
| 790 | + |
|
| 791 | +Notice the presence of 'A' and 'B'... these are not variables or |
|
| 792 | +algebraic values. These are bonafide **NUMBERS**, just like 1, 2, 3. |
|
| 793 | + |
|
| 794 | +Differences manifest once you exceed the maximum counting value for the base: |
|
| 795 | + |
|
| 796 | + * base 8: 7 + 1 = 10 (pronounced "one-zero", the quantity we know of in base 10 as "eight") |
|
| 797 | + * base 9: 8 + 1 = 10 (pronounced "one-zero", the quantity we know of in base 10 as "nine") |
|
| 798 | + * base 10: 9 + 1 = 10 (pronounced "one-zero", the quantity we know of in base 10 as "ten") |
|
| 799 | + * base 11: A + 1 = 10 (pronounced "one-zero", the quantity we know of in base 10 as "eleven") |
|
| 800 | + * base 12: B + 1 = 10 (pronounced "one-zero", the quantity we know of in base 10 as "twelve") |
|
| 801 | + |
|
| 802 | +You likely have extensively memorized a table of single-digit base 10 |
|
| 803 | +values, which at first glance makes this other base stuff unfamiliar. But |
|
| 804 | +it works according to the same properties as base 10 (just, different |
|
| 805 | +symbols representing the quantities involved). |
|
| 806 | + |
|
| 807 | +For any strategies involving the "9" value (in base 10), you will find |
|
| 808 | +that the same strategy works in other bases (so it isn't so much a "9 |
|
| 809 | +trick" as it is a "highest counting digit trick"). |
|
| 810 | + |
|
| 811 | +Similarly, any of the relational or logical tricks will "just work", it |
|
| 812 | +is only the appearance of mathematical end results that really differs. |
|
| 813 | +So, if you are adept at the logical/relational methods for investigating |
|
| 814 | +a puzzle, you could perhaps minimize the amount of base-related math you |
|
| 815 | +may have to do (certainly on lower difficulty levels of puzzle). |
|
| 816 | + |
|
| 817 | +## YOUR SUBMISSION |
|
| 818 | + |
|
| 819 | +### SUBMISSION FOR REGULAR LETTER DIVISION |
|
| 820 | + |
|
| 821 | +If your puzzle was provided with a quotient and remainder (and contains |
|
| 822 | +no question marks in the puzzle proper), you have a regular puzzle. |
|
| 823 | + |
|
| 824 | +The files you will want to submit include: |
|
| 825 | + |
|
| 826 | + * your puzzle key, in a textfile called 'pctX.puzzle.key' containing ONLY the capital letters corresponding in order to the 0-9 values (and a trailing newline). |
|
| 827 | + * your documentation of your solving and exploration of the puzzle. If you did this on paper, will need to transcribe it out into clearly readable, organized, and followable text directions. The file, in text form, should be called 'pctX.puzzle.solution'. Images of your notes will NOT be accepted for submission. |
|
| 828 | + * your verification in a file called 'pctX.puzzle.verify': this is after you've completed the puzzle, and you are resolving parts of the puzzle to ensure that the letter to number mappings are valid. |
|
| 829 | + |
|
| 830 | +Your solution MUST be of a form so that, if given to another person, they |
|
| 831 | +can follow your steps and have an understanding of the decisions made. |
|
| 832 | + |
|
| 833 | +### SUBMISSION FOR SOLVE4 LETTER DIVISION |
|
| 834 | + |
|
| 835 | +The point behind a "solve4" puzzle is to also determine the `QUOTIENT` and `REMAINDER`, in addition to the key. |
|
| 836 | + |
|
| 837 | + * your puzzle key, in a textfile called 'pctX.puzzle.key' containing ONLY the capital letters corresponding in order to the 0-9 values (and a trailing newline). |
|
| 838 | + * your documentation of your solving and exploration of the puzzle. If you did this on paper, will need to transcribe it out into clearly readable, organized, and followable text directions. The file, in text form, should be called 'pctX.puzzle.solution'. Images of your notes will NOT be accepted for submission. |
|
| 839 | + * your quotient:remainder (in letterized/obfuscated form), in a text file called 'pctX.puzzle.verify' |
|
| 840 | + |
|
| 841 | +Your solution MUST be of a form so that, if given to another person, they |
|
| 842 | +can follow your steps and have an understanding of the decisions made to |
|
| 843 | +get them from start to solution. |
|
| 844 | + |
|
| 845 | +## PUZZLE KEY |
|
| 846 | + |
|
| 847 | +As indicated, you are to place the determined key to your puzzle in a |
|
| 848 | +regular text file called 'pctX.puzzle.key', and will contain ONLY the |
|
| 849 | +capital letters, in order from 0 to the highest counting symbol of the |
|
| 850 | +base, of your puzzle (and a trailing newline). |
|
| 851 | + |
|
| 852 | +For example, using the example puzzle above: |
|
| 853 | + |
|
| 854 | +| 0 | R | |
|
| 855 | +| 1 | B | |
|
| 856 | +| 2 | V | |
|
| 857 | +| 3 | G | |
|
| 858 | +| 4 | P | |
|
| 859 | +| 5 | M | |
|
| 860 | +| 6 | O | |
|
| 861 | +| 7 | L | |
|
| 862 | +| 8 | J | |
|
| 863 | +| 9 | K | |
|
| 864 | + |
|
| 865 | +We'll want to put them, in order, in our key file: |
|
| 866 | + |
|
| 867 | +``` |
|
| 868 | +$ echo "RBVGPMOLJK" > pctX.puzzle.key |
|
| 869 | +``` |
|
| 870 | + |
|
| 871 | +Want to know what a proper 'key' file should look like? This: |
|
| 872 | + |
|
| 873 | +``` |
|
| 874 | +$ cat pctX.puzzle.key |
|
| 875 | +RBVGPMOLJK |
|
| 876 | +``` |
|
| 877 | + |
|
| 878 | +JUST the letters (and a trailing newline). |
|
| 879 | + |
|
| 880 | +## PUZZLE SOLUTION |
|
| 881 | + |
|
| 882 | +As stated, a very large part of this project's evaluation will be based |
|
| 883 | +on your clear and detailed documentation of how you determined each |
|
| 884 | +letter's mapping in the solution key of your puzzle. |
|
| 885 | + |
|
| 886 | +Just providing the 'key' will not result in success. |
|
| 887 | + |
|
| 888 | +Your documentation should, while there may be supporting information, |
|
| 889 | +provide some identified path that showed the steps you went through to |
|
| 890 | +identify each letter, be it directly or indirectly. |
|
| 891 | + |
|
| 892 | +You are free to write out your solution with pen on paper (that is how I |
|
| 893 | +usually do these puzzles); but to submit, you MUST transcribe it to text |
|
| 894 | +and submit it in that format. Images will NOT be accepted. Do not look on |
|
| 895 | +this as a reason to avoid doing it by hand: the manual work of the |
|
| 896 | +process is inherently beneficial, you simply need to commit to doing it. |
|
| 897 | + |
|
| 898 | +The aim here is not to dump a bunch of data on me, but instead present me |
|
| 899 | +with connected and pertinent information that documents your process of |
|
| 900 | +progression through the puzzle from start to finish. This is in the same |
|
| 901 | +vein as programming in a language on a computer. A computer program is a |
|
| 902 | +detailed description of a process to solving some problem in a format the |
|
| 903 | +receiver can understand. |
|
| 904 | + |
|
| 905 | +## VERIFICATION |
|
| 906 | + |
|
| 907 | +Depending on the type of puzzle you have (regular or "solve for" |
|
| 908 | +variety), the contents of your verification file will differ. |
|
| 909 | + |
|
| 910 | +What is the difference between a regular puzzle and a solve4 puzzle? |
|
| 911 | +Basically: |
|
| 912 | + |
|
| 913 | + * a regular puzzle comes with quotient and remainder included in your puzzle |
|
| 914 | + * a solve4 puzzle omits the quotient and remainder, and instead replaces them with a series of question marks, indicating that as part of your task in solving the puzzle, you must also figure out the quotient and remainder (this is why the verify for solve4 puzzles is shorter and simpler: you've already done so much of the verification work in solving it). |
|
| 915 | + |
|
| 916 | +### REGULAR PUZZLE |
|
| 917 | + |
|
| 918 | +In this form, your 'pctX.puzzle.verify' file will be similar format to |
|
| 919 | +your writeup (a description of what aspects of the puzzle you are testing |
|
| 920 | +to ensure things work out). |
|
| 921 | + |
|
| 922 | +You are to manually verify your solution by taking the numeric identities |
|
| 923 | +of each letter, plugging them back into the original puzzle, solving it, |
|
| 924 | +and converting the obtained quotient and remainder back into letter form |
|
| 925 | +to compare with those in the puzzle provided to you. If they match, you |
|
| 926 | +have successfully solved the puzzle. If they do not match, some error |
|
| 927 | +exists that should be addressed and corrected. |
|
| 928 | + |
|
| 929 | +An example of a verification text can be found below. |
|
| 930 | + |
|
| 931 | +### EXAMPLE FOR REGULAR PUZZLE |
|
| 932 | + |
|
| 933 | +The best way to verify the puzzle with our key is to convert the dividend |
|
| 934 | +and divisor to its numeric equivalent, perform the division, and |
|
| 935 | +compare the resulting quotient and remainder against those found in the |
|
| 936 | +letterified puzzle: |
|
| 937 | + |
|
| 938 | + * divisor: KJKK --> 9899 |
|
| 939 | + * dividend: GLMBRVLR --> 37510270 |
|
| 940 | + |
|
| 941 | +And let's do some long division! |
|
| 942 | + |
|
| 943 | +``` |
|
| 944 | + +--------- |
|
| 945 | + 9899 | 37510270 |
|
| 946 | +``` |
|
| 947 | + |
|
| 948 | +9899 goes into 37510 three times: |
|
| 949 | + |
|
| 950 | +``` |
|
| 951 | + 3 |
|
| 952 | + +--------- |
|
| 953 | + 9899 | 37510270 |
|
| 954 | + -29697 |
|
| 955 | + ===== |
|
| 956 | + 78132 |
|
| 957 | +``` |
|
| 958 | + |
|
| 959 | +It might be convenient to have a quick factor reference for 9899 handy: |
|
| 960 | + |
|
| 961 | + * 9899 * 0 = 0 |
|
| 962 | + * 9899 * 1 = 9899 |
|
| 963 | + * 9899 * 2 = 19798 |
|
| 964 | + * 9899 * 3 = 29697 |
|
| 965 | + * 9899 * 4 = 39596 |
|
| 966 | + * 9899 * 5 = 49495 |
|
| 967 | + * 9899 * 6 = 59394 |
|
| 968 | + * 9899 * 7 = 69293 |
|
| 969 | + * 9899 * 8 = 79192 |
|
| 970 | + * 9899 * 9 = 89091 |
|
| 971 | + |
|
| 972 | +9899 fits into 78132 seven times (69293): |
|
| 973 | + |
|
| 974 | +``` |
|
| 975 | + 37 |
|
| 976 | + +--------- |
|
| 977 | + 9899 | 37510270 |
|
| 978 | + -29697 |
|
| 979 | + ===== |
|
| 980 | + 78132 |
|
| 981 | + -69293 |
|
| 982 | + ===== |
|
| 983 | + 88397 |
|
| 984 | +``` |
|
| 985 | + |
|
| 986 | +Once again, looking at the list of factors, we see that the best fit for 9899 into 88397 is 79192 (a factor of 8): |
|
| 987 | + |
|
| 988 | +``` |
|
| 989 | + 378 |
|
| 990 | + +--------- |
|
| 991 | + 9899 | 37510270 |
|
| 992 | + -29697 |
|
| 993 | + ===== |
|
| 994 | + 78132 |
|
| 995 | + -69293 |
|
| 996 | + ===== |
|
| 997 | + 88397 |
|
| 998 | + -79192 |
|
| 999 | + ===== |
|
| 1000 | + 92050 |
|
| 1001 | +``` |
|
| 1002 | + |
|
| 1003 | +Finally, a factor of 9 (89091) fits in best: |
|
| 1004 | + |
|
| 1005 | +``` |
|
| 1006 | + 3789 <-- quotient |
|
| 1007 | + +--------- |
|
| 1008 | + 9899 | 37510270 |
|
| 1009 | + -29697 |
|
| 1010 | + ===== |
|
| 1011 | + 78132 |
|
| 1012 | + -69293 |
|
| 1013 | + ===== |
|
| 1014 | + 88397 |
|
| 1015 | + -79192 |
|
| 1016 | + ===== |
|
| 1017 | + 92050 |
|
| 1018 | + -89091 |
|
| 1019 | + ===== |
|
| 1020 | + 2959 <-- remainder |
|
| 1021 | +``` |
|
| 1022 | + |
|
| 1023 | +Converting our quotient and remainder back to letters: |
|
| 1024 | + |
|
| 1025 | + * quotient: 3789 --> GLJK |
|
| 1026 | + * remainder: 2959 --> VKMK |
|
| 1027 | + |
|
| 1028 | +And comparing against the problem we were given: |
|
| 1029 | + |
|
| 1030 | + * quotient: GLJK <-> GLJK |
|
| 1031 | + * remainder: VKMK <-> VKMK |
|
| 1032 | + |
|
| 1033 | +Success! |
|
| 1034 | + |
|
| 1035 | +## SOLVE4 PUZZLE |
|
| 1036 | + |
|
| 1037 | +The verification for these puzzles becomes a bit easier, as you are |
|
| 1038 | +merely providing the quotient and remainder. |
|
| 1039 | + |
|
| 1040 | +Let's say the quotient was "BTXMK" and the remainder was "YYGMX" |
|
| 1041 | + |
|
| 1042 | +You'd prepare your 'pctX.puzzle.verify' file as follows: |
|
| 1043 | + |
|
| 1044 | +``` |
|
| 1045 | +$ echo "BTXMK:YYGMX" > pctX.puzzle.verify |
|
| 1046 | +``` |
|
| 1047 | + |
|
| 1048 | +Basically: quotient followed by remainder, separated by a colon, all on |
|
| 1049 | +the same line. |
|
| 1050 | + |
|
| 1051 | +NOTE: Do not include any leading zeroes. |
|
| 1052 | + |
|
| 1053 | +## WALKTHROUGH VIDEOS |
|
| 1054 | + |
|
| 1055 | +To further aid your letter division efforts, I have recorded some videos |
|
| 1056 | +showing my walkthrough of various letter division puzzles: |
|
| 1057 | + |
|
| 1058 | + * [another take on the puzzle presented on this page](https://youtu.be/8oCoGGspf70) |
|
| 1059 | + * [a base 8 letter division puzzle](https://www.youtube.com/watch?v=2Zoa6iymxpw) |
|
| 1060 | + * [a base 9 letter division puzzle](https://www.youtube.com/watch?v=zil4YjgC6bw) |
|
| 1061 | + * [a base 10 letter division puzzle](https://www.youtube.com/watch?v=b6wv9zXlbJE) |
|
| 1062 | + * [a base 11 letter division puzzle](https://youtu.be/OHrLOVihi_4) |
|
| 1063 | + |
|
| 1064 | +## STRATEGIES |
|
| 1065 | + |
|
| 1066 | +### LEFT EDGE |
|
| 1067 | + |
|
| 1068 | +An advantage of the left-most values, is the top value is greater than |
|
| 1069 | +those beneath it (it doesn't need to borrow; indeed it CANNOT borrow, |
|
| 1070 | +without breaking math). Might be taken from, however... |
|
| 1071 | + |
|
| 1072 | +This can also help establish the state of borrows elsewhere in the |
|
| 1073 | +puzzle, should a similar subtraction (same top-value) be present in more |
|
| 1074 | +than one place. |
|
| 1075 | + |
|
| 1076 | +For example: |
|
| 1077 | + |
|
| 1078 | +``` |
|
| 1079 | + WXXY |
|
| 1080 | + -PQRT |
|
| 1081 | + ==== |
|
| 1082 | + GCBA |
|
| 1083 | +``` |
|
| 1084 | + |
|
| 1085 | + * W-P=G |
|
| 1086 | + * P << W (P is somewhat less than W) |
|
| 1087 | + * G << W (G is somewhat less than W) |
|
| 1088 | + |
|
| 1089 | +NOTE: from this example alone, we do NOT know P's relationship to G. |
|
| 1090 | + |
|
| 1091 | +## DETERMINE BORROWS AND TAKES |
|
| 1092 | + |
|
| 1093 | +Like the range table and your chains of assertions gradually assembled |
|
| 1094 | +during puzzle solving, another activity you should undertake is the |
|
| 1095 | +determination of all the borrows/takes in the puzzle. |
|
| 1096 | + |
|
| 1097 | +And not just IF there is a borrow/take, but also if there isn't one. |
|
| 1098 | + |
|
| 1099 | +Many may remember the idea of borrows from math class, and are confused |
|
| 1100 | +at what a "take" is: this is just our attempt to connect one subtraction |
|
| 1101 | +into the tapestry of the overall problem. |
|
| 1102 | + |
|
| 1103 | +Take the following numeric example: |
|
| 1104 | + |
|
| 1105 | +``` |
|
| 1106 | + 545 |
|
| 1107 | +-347 |
|
| 1108 | + === |
|
| 1109 | + 198 |
|
| 1110 | +``` |
|
| 1111 | + |
|
| 1112 | +Notice how, looking at the 5-7=8 subtraction (on the far right), we can |
|
| 1113 | +see that the 5 is somewhat less than 7 (and the 8), so that 5 would have |
|
| 1114 | +to borrow. |
|
| 1115 | + |
|
| 1116 | +Being all the way on the right, nothing is able to take from it, so that |
|
| 1117 | +5 is borrowing, but not being taken from. |
|
| 1118 | + |
|
| 1119 | +Onto the 4-4=9… because the 5 to its right is needing to borrow… what |
|
| 1120 | +is it borrowing from? The 4. So our 4 is being "taken from". |
|
| 1121 | + |
|
| 1122 | + * 4-1=3 |
|
| 1123 | + |
|
| 1124 | +3 is less than 4 (And 9), so THAT now has to borrow. |
|
| 1125 | + |
|
| 1126 | +So the 4 is being taken from, and as a result, needs to borrow. |
|
| 1127 | + |
|
| 1128 | +Then proceeding left to the 5-3=1... being all the way on the left, |
|
| 1129 | +it can’t borrow from anything, and the universe would explode |
|
| 1130 | +mathematically if the leftmost, top value in a long division term were |
|
| 1131 | +less than what was being subtracted from it. So, the 5 does not have to |
|
| 1132 | +borrow. But we know from the 4-4=9 subtraction, that the 4 borrows, and |
|
| 1133 | +it is borrowing from the 5 |
|
| 1134 | + |
|
| 1135 | +So: that left-most 5 is not borrowing, but it IS being taken from. |
|
| 1136 | + |
|
| 1137 | +The state of the borrows/takes greatly enhances our ability to scoop up |
|
| 1138 | +additional clues we can turn into assertions. |
|
| 1139 | + |
|
| 1140 | +## TOP IS KNOWN GREATER THAN |
|
| 1141 | + |
|
| 1142 | +When we know the top letter is greater than at least one of the other two |
|
| 1143 | +numbers in the subtraction, turns out it is also greater than the other: |
|
| 1144 | + |
|
| 1145 | +``` |
|
| 1146 | + 8 7 6 5 |
|
| 1147 | +-5 -1 -4 -2 |
|
| 1148 | +== == == == |
|
| 1149 | + 3 6 2 3 |
|
| 1150 | +``` |
|
| 1151 | + |
|
| 1152 | +This can also help establish the state of borrows elsewhere in the |
|
| 1153 | +puzzle, should a similar subtraction (same top-value and other letter) be |
|
| 1154 | +present in more than one place. |
|
| 1155 | + |
|
| 1156 | +When the top is known to be greater than the or a number beneath, it |
|
| 1157 | +signifies that NO BORROW is happening. |
|
| 1158 | + |
|
| 1159 | +NOTE: this doesn't tell us anything about the TAKE situation. |
|
| 1160 | + |
|
| 1161 | +## TOP IS KNOWN LESS THAN |
|
| 1162 | + |
|
| 1163 | +When we know the top letter is less than at least one of the other two |
|
| 1164 | +numbers in the subtraction, turns out it is also less than the other: |
|
| 1165 | + |
|
| 1166 | +``` |
|
| 1167 | +13 12 16 11 |
|
| 1168 | +-5 -3 -7 -4 |
|
| 1169 | +== == == == |
|
| 1170 | + 8 9 9 7 |
|
| 1171 | +``` |
|
| 1172 | + |
|
| 1173 | +This can also help establish the state of borrows elsewhere in the |
|
| 1174 | +puzzle, should a similar subtraction (same top-value and other letter) be |
|
| 1175 | +present in more than one place. |
|
| 1176 | + |
|
| 1177 | +When the top is known to be less than the or a number beneath, it |
|
| 1178 | +signifies that a BORROW is happening. |
|
| 1179 | + |
|
| 1180 | +NOTE: this doesn't tell us anything about the TAKE situation. |
|
| 1181 | + |
|
| 1182 | +## RIGHT EDGE |
|
| 1183 | + |
|
| 1184 | +We know from right-most values, that they are NOT being taken from. |
|
| 1185 | + |
|
| 1186 | +This can also help establish the state of takes elsewhere in the puzzle, |
|
| 1187 | +should an identical subtraction be present in more than one place. |
|
| 1188 | + |
|
| 1189 | +## LOOK FOR ZERO AND GREATEST SYMBOL CANDIDATES |
|
| 1190 | + |
|
| 1191 | +There are two common give-away cases for finding the two extreme digits |
|
| 1192 | +(least/lowest/zero and greatest/highest) in a puzzle, regardless of base: |
|
| 1193 | + |
|
| 1194 | +``` |
|
| 1195 | + X |
|
| 1196 | + -X |
|
| 1197 | + = |
|
| 1198 | + Y |
|
| 1199 | +``` |
|
| 1200 | + |
|
| 1201 | +and: |
|
| 1202 | + |
|
| 1203 | +``` |
|
| 1204 | + X |
|
| 1205 | + -Y |
|
| 1206 | + = |
|
| 1207 | + X |
|
| 1208 | +``` |
|
| 1209 | + |
|
| 1210 | +We don't, simply from this display, know if it is 0 or if it is the |
|
| 1211 | +greatest digit. Merely that it can only be 0 or the greatest digit. |
|
| 1212 | + |
|
| 1213 | +Determining the identity of the letter (Y in these examples) depends on |
|
| 1214 | +the state of borrow/takings for the subtraction. |
|
| 1215 | + |
|
| 1216 | +There really are only TWO possibilities here: |
|
| 1217 | + |
|
| 1218 | + * no borrow AND no take (Y would be 0) |
|
| 1219 | + * borrow AND take (Y would be the greatest digit) |
|
| 1220 | + |
|
| 1221 | +The other two scenarios are mathematically impossible given this |
|
| 1222 | +particular pattern (again, ONLY for 0, greatest digit scenario). |
|
| 1223 | + |
|
| 1224 | +## PROCESS OF ELIMINATION |
|
| 1225 | + |
|
| 1226 | +A tactic that sees use in almost any puzzle is that of elimination: or |
|
| 1227 | +using logic to negate possibilities. |
|
| 1228 | + |
|
| 1229 | +For example: |
|
| 1230 | + |
|
| 1231 | +``` |
|
| 1232 | + ABCD |
|
| 1233 | +-EFGH |
|
| 1234 | + ==== |
|
| 1235 | + JKLM |
|
| 1236 | +``` |
|
| 1237 | + |
|
| 1238 | +Looking at that right-most subtraction (D-H=M), even if we know NOTHING |
|
| 1239 | +about D, H, or M, we can, however, ascertain that: |
|
| 1240 | + |
|
| 1241 | + * H is NOT zero |
|
| 1242 | + * M is NOT zero |
|
| 1243 | + |
|
| 1244 | +Because none of the zero patterns are manifesting (if we had D-H=D, for |
|
| 1245 | +instance, in that right-most position, we'd KNOW that H was zero), we can |
|
| 1246 | +categorically eliminate zero as a possibility for the two lower letters |
|
| 1247 | +in this subtraction (NOTE: D very well COULD BE zero, but we can't do |
|
| 1248 | +anything about determining yet solely based on this observation). |
|
| 1249 | + |
|
| 1250 | +This strategy would work in other places, too, if sufficient |
|
| 1251 | +borrows/takes were known. |
|
| 1252 | + |
|
| 1253 | +For example, in A-E=J, if we had established that A was NOT being taken |
|
| 1254 | +from, we could apply this same elimination to E and J (not zero). |
|
| 1255 | + |
|
| 1256 | +Or B-F=K, or C-G=L, if we knew we weren't being taken from. But if we |
|
| 1257 | +don't know the take situation, we cannot yet act on this. |
|
| 1258 | + |
|
| 1259 | +## DOUBLING |
|
| 1260 | + |
|
| 1261 | +Sometimes we will be treated to things like: |
|
| 1262 | + |
|
| 1263 | +``` |
|
| 1264 | + T |
|
| 1265 | + -P |
|
| 1266 | + = |
|
| 1267 | + P |
|
| 1268 | +``` |
|
| 1269 | + |
|
| 1270 | +Which implies T is double the value of P. |
|
| 1271 | + |
|
| 1272 | +This isn't the whole story, as we REALLY need to know the borrow/take |
|
| 1273 | +situation to do anything with this information. |
|
| 1274 | + |
|
| 1275 | +For example, for an even base: if T is being TAKEN FROM, we know that T |
|
| 1276 | +is odd. Likewise, if it is NOT being taken from, T is even. |
|
| 1277 | + |
|
| 1278 | +Also: |
|
| 1279 | + |
|
| 1280 | + * If T does NOT borrow, P+P is some value less than 10. |
|
| 1281 | + * If T DOES borrow, P+P is some value greater than or equal to 10. |
|
| 1282 | + |
|
| 1283 | +In either case of T being odd or even, we can eliminate half the values |
|
| 1284 | +(if T is even, it cannot be any odd values, not in an even base). |
|
| 1285 | + |
|
| 1286 | +## NEXT TO HINTS |
|
| 1287 | + |
|
| 1288 | +Sometimes you may be treated to left-most clues like this: |
|
| 1289 | + |
|
| 1290 | +``` |
|
| 1291 | + JKLM |
|
| 1292 | + -FGHH |
|
| 1293 | + ==== |
|
| 1294 | + TWX |
|
| 1295 | +``` |
|
| 1296 | + |
|
| 1297 | +Notice how J-F equals nothing? That tells us the following things: |
|
| 1298 | + |
|
| 1299 | + * F is exactly one value less than J (written: F < J) |
|
| 1300 | + * K is LESS THAN G and T (K has to borrow to make J-F=0 versus the 1 it would otherwise be). |
|
| 1301 | + |
|
| 1302 | +## MORE NEXT TO HINTS |
|
| 1303 | + |
|
| 1304 | +What really pays off is when we have a scenario like this: |
|
| 1305 | + |
|
| 1306 | +``` |
|
| 1307 | + JKLJM |
|
| 1308 | + -FGHFH |
|
| 1309 | + ===== |
|
| 1310 | + TWUX |
|
| 1311 | +``` |
|
| 1312 | + |
|
| 1313 | +See that nestled J-F=U there? Because we had the left-most J-F=NOTHING |
|
| 1314 | +establishing our assertion that F < J, yet NOT knowing the state of being |
|
| 1315 | +taken from (ie not knowing anything about M against H or X): |
|
| 1316 | + |
|
| 1317 | + * U is EITHER 0 or 1, to be immediately determined once we know the state of M against H or X (the subtraction immediately to the right). |
|
| 1318 | + |
|
| 1319 | +## SUBTRACT BY GREATEST DIGIT, GET INCREMENT |
|
| 1320 | + |
|
| 1321 | +If we have identified the greatest value, and we see it elsewhere in the |
|
| 1322 | +puzzle, NOT as the top value, but as the value being subtracted, or the |
|
| 1323 | +result, and we are not being taken from, we know some things. |
|
| 1324 | + |
|
| 1325 | +For example, let's say C is the greatest digit (9 in base 10), and E << |
|
| 1326 | +T: |
|
| 1327 | + |
|
| 1328 | +``` |
|
| 1329 | + PHANT |
|
| 1330 | + - OMME |
|
| 1331 | + ===== |
|
| 1332 | + NACE |
|
| 1333 | +``` |
|
| 1334 | + |
|
| 1335 | +See the N-M=C ? |
|
| 1336 | + |
|
| 1337 | +Because we know C is 9: |
|
| 1338 | + |
|
| 1339 | + * N << C (everything not C is less than C (9)) |
|
| 1340 | + * therefore also: N << M |
|
| 1341 | + |
|
| 1342 | +Watch what happens when we plug in values: |
|
| 1343 | + |
|
| 1344 | + * N = 1: 11-9=2 |
|
| 1345 | + * N = 2: 12-9=3 |
|
| 1346 | + * N = 3: 13-9=4 |
|
| 1347 | + * N = 4: 14-9=5 |
|
| 1348 | + * ... through N=7 |
|
| 1349 | + |
|
| 1350 | +Notice how when N is 1, M is 2... 2, 3... 3, 4... ? |
|
| 1351 | + |
|
| 1352 | +In this scenario: N is EXACTLY ONE LESS than M: N < M. |
|
| 1353 | + |
|
| 1354 | +But only when we KNOW what the greatest digit in a base is and know the |
|
| 1355 | +state of whether or not we are being taken from. |
|
| 1356 | + |
|
| 1357 | +## SUBTRACT BY KNOWN OFFSET FROM GREATEST DIGIT, GET OFFSET INCREMENT |
|
| 1358 | + |
|
| 1359 | +Related to the above strategy, on "Subtract by greatest digit, get |
|
| 1360 | +increment", it actually applies to more than just the greatest digit: so |
|
| 1361 | +long as you know its distance from the greatest digit, and the take |
|
| 1362 | +situation of the subtraction, you can derive the offset of increment. |
|
| 1363 | + |
|
| 1364 | +A chart of the first few (I typically don't go any further than this out |
|
| 1365 | +of practicality, although the pattern persists beyond this point of |
|
| 1366 | +reporting): |
|
| 1367 | + |
|
| 1368 | +| digit | being taken from | not being taken from | |
|
| 1369 | +| ---------- | ---------------- | -------------------- | |
|
| 1370 | +| greatest | 0 | 1 | |
|
| 1371 | +| greatest-1 | 1 | 2 | |
|
| 1372 | +| greatest-2 | 2 | 3 | |
|
| 1373 | + |
|
| 1374 | +For example, let's say R is the second greatest digit (A in base 12), and |
|
| 1375 | +let's say we know that C << R: |
|
| 1376 | + |
|
| 1377 | +``` |
|
| 1378 | + SECOND |
|
| 1379 | + - GRADE |
|
| 1380 | + ====== |
|
| 1381 | + MATHS |
|
| 1382 | +``` |
|
| 1383 | + |
|
| 1384 | +See the C-R=A? With R being the known second greatest digit, and knowing |
|
| 1385 | +that C is somewhat less than R, that means C is borrowing. |
|
| 1386 | + |
|
| 1387 | +Looking at the table, depending on the take situation, we can determine |
|
| 1388 | +that C is exactly 1 or 2 values less than A, potentially offing up nice |
|
| 1389 | +reduction of possibilities for both C and A. |
|
| 1390 | + |
|
| 1391 | +Should it turn out C is being taken from, then C is exactly 1 less than |
|
| 1392 | +A. |
|
| 1393 | + |
|
| 1394 | +If C is not being taken from, then C is exactly 2 less than A. |
|
| 1395 | + |
|
| 1396 | +## DIVISOR/MULTIPLICATION RELATIONS |
|
| 1397 | + |
|
| 1398 | +Since letter divisions are but a long division, if we were to look at one |
|
| 1399 | +(base 10) as purely numbers: |
|
| 1400 | + |
|
| 1401 | +``` |
|
| 1402 | + 2565 |
|
| 1403 | + +--------- |
|
| 1404 | +27846 | 71447493 |
|
| 1405 | + -55692 |
|
| 1406 | + ===== |
|
| 1407 | + 157554 |
|
| 1408 | + -139230 |
|
| 1409 | + ====== |
|
| 1410 | + 183249 |
|
| 1411 | + -167076 |
|
| 1412 | + ====== |
|
| 1413 | + 161733 |
|
| 1414 | + -139230 |
|
| 1415 | + ====== |
|
| 1416 | + 22503 |
|
| 1417 | +``` |
|
| 1418 | + |
|
| 1419 | +Do you see that the divisor (27846) x 2 = 55692, divisor x 5 = 139230, |
|
| 1420 | +and divisor x 6 = 167076? |
|
| 1421 | + |
|
| 1422 | +Pay specific attention to the subtrahend of 55692. Notice how it is |
|
| 1423 | +exactly the same length in digits as the divisor (5 digits). This allows |
|
| 1424 | +us to make an important comparison: |
|
| 1425 | + |
|
| 1426 | + * divisor (27846) x 1 = the divisor itself (27846). |
|
| 1427 | + * any similarly-lengthed subtrahend as the divisor is NOT less than the divisor. |
|
| 1428 | + * so we can make a comparison between the first digits of the divisor and that of the subtrahend. |
|
| 1429 | + |
|
| 1430 | +In a fully enlettered puzzle: |
|
| 1431 | + |
|
| 1432 | +``` |
|
| 1433 | + TECE |
|
| 1434 | + +--------- |
|
| 1435 | +TMGNC | MSNNMNXL |
|
| 1436 | + -EECXT |
|
| 1437 | + ===== |
|
| 1438 | + SEMEEN |
|
| 1439 | + -SLXTLR |
|
| 1440 | + ====== |
|
| 1441 | + SGLTNX |
|
| 1442 | + -SCMRMC |
|
| 1443 | + ====== |
|
| 1444 | + SCSMLL |
|
| 1445 | + -SLXTLR |
|
| 1446 | + ====== |
|
| 1447 | + TTERL |
|
| 1448 | +``` |
|
| 1449 | + |
|
| 1450 | +In the case of TMGNC (the divisor) and EECXT (that first subtrahend), |
|
| 1451 | +specifically their first letters (T and E), because they are both the |
|
| 1452 | +same length (5 letters), we can establish the following relation: |
|
| 1453 | + |
|
| 1454 | + * T << E (T is somewhat less than E) |
|
| 1455 | + * by extension, the minuend the subtrahend is being subtracted from, has to be at least the same size or larger than the subtrahend. So, similarly, in TMGNC (the divisor) and MSNNM (5 letters), T << M (T is somewhat less than M. |
|
| 1456 | + |
|
| 1457 | +This strategy, making use of multiplication, can only be used on puzzles |
|
| 1458 | +where multiplication has not been restricted. |
|
| 1459 | + |
|
| 1460 | +## INVERTED SUBTRACTION PAIRS |
|
| 1461 | + |
|
| 1462 | +Given the following puzzle: |
|
| 1463 | + |
|
| 1464 | +``` |
|
| 1465 | + SETX |
|
| 1466 | + +--------- |
|
| 1467 | +EXEXT | XSSEMLMS |
|
| 1468 | + -EXEXT |
|
| 1469 | + ===== |
|
| 1470 | + LSECEL |
|
| 1471 | + -TXMXCR |
|
| 1472 | + ====== |
|
| 1473 | + SMCXLM |
|
| 1474 | + -SSXSGN |
|
| 1475 | + ====== |
|
| 1476 | + EMMELS |
|
| 1477 | + -ELCLTG |
|
| 1478 | + ====== |
|
| 1479 | + NSTRL |
|
| 1480 | + |
|
| 1481 | +base: 10 |
|
| 1482 | +``` |
|
| 1483 | + |
|
| 1484 | +Have you ever noticed patterns like the following: |
|
| 1485 | + |
|
| 1486 | + * M-T=E (1st row, right-most) |
|
| 1487 | + * E-M=M (2nd row, 3rd from left) |
|
| 1488 | + |
|
| 1489 | +or: |
|
| 1490 | + |
|
| 1491 | + * X-E=L (1st row, left-most) |
|
| 1492 | + * E-X=C (1st row, 2nd from right) |
|
| 1493 | + |
|
| 1494 | +Basically, two different subtractions that match the following pattern: |
|
| 1495 | + |
|
| 1496 | + * top letter in one is a middle/bottom letter in the other |
|
| 1497 | + * middle/bottom letter in the first is the top in the other |
|
| 1498 | + |
|
| 1499 | +... as is the case in those two identified examples: M (top), E (bottom) |
|
| 1500 | +and E(top), M (middle/bottom) |
|
| 1501 | + |
|
| 1502 | +or: X (top), E (middle) and then E (top), X (middle). |
|
| 1503 | + |
|
| 1504 | +When you have scenarios such as this we can assume something about the |
|
| 1505 | +sum of the OTHER two letters involved: |
|
| 1506 | + |
|
| 1507 | + * (E,X) C + L |
|
| 1508 | + * (E,M) M + T |
|
| 1509 | + |
|
| 1510 | +There are actually three possible sums, all dependent upon the state of |
|
| 1511 | +the takes: |
|
| 1512 | + |
|
| 1513 | +| no take from either | take from one but not the other | take from both | |
|
| 1514 | +| ------------------- | ------------------------------- | -------------- | |
|
| 1515 | +| the base | the base - 1 | the base - 2 | |
|
| 1516 | + |
|
| 1517 | +So, in the case of M-T=E and E-M=M, because M-T=E is on the right edge, |
|
| 1518 | +we know it cannot be taken from, so then we only need to determine the |
|
| 1519 | +take situation for E-M=M. Therefore, there are TWO potential answers for |
|
| 1520 | +M+T: |
|
| 1521 | + |
|
| 1522 | + * (no takes) M + T = 10 |
|
| 1523 | + * (one take) M + T = 9 |
|
| 1524 | + |
|
| 1525 | +... since the base of the puzzle is 10, 10 is the sum when there are no |
|
| 1526 | +takes involved on the two subtractions. For other bases, it is still "one |
|
| 1527 | +zero", but obviously the quantity of that base. |
|
| 1528 | + |
|
| 1529 | +The other identified pair in this example; the case of X-E=L and E-X=C, |
|
| 1530 | +both are within a line, so no immediate clues as to certain states on |
|
| 1531 | +take/no take. Therefore: |
|
| 1532 | + |
|
| 1533 | + * (no takes) C + L = 10 |
|
| 1534 | + * (one take) C + L = 9 |
|
| 1535 | + * (two takes) C + L = 8 |
|
| 1536 | + |
|
| 1537 | +This tends to be a nice way of accruing additional clues not revealed |
|
| 1538 | +in more common methods, increasing the chances of increasing letter |
|
| 1539 | +connectivity and deriving an eventual solution. |
|
| 1540 | + |
|
| 1541 | +## INVERTED SUBTRACTION RELATIONAL PAIRS |
|
| 1542 | + |
|
| 1543 | +Similar to the above strategy, what happens if you identify two |
|
| 1544 | +subtraction pairs, but instead of involving the same symbols, involves a |
|
| 1545 | +pair of symbols based on a known relation (off by one, in either |
|
| 1546 | +direction). |
|
| 1547 | + |
|
| 1548 | +The same core logic applies (factoring in the take situation on both). |
|
| 1549 | + |
|
| 1550 | +But we can also add additional influence based on the relation of the |
|
| 1551 | +symbols being modulated. |
|
| 1552 | + |
|
| 1553 | +For instance, if we were to have a known relation of `R < C`, and we had |
|
| 1554 | +the following: |
|
| 1555 | + |
|
| 1556 | +``` |
|
| 1557 | + X C |
|
| 1558 | + -P -G |
|
| 1559 | + = = |
|
| 1560 | + R X |
|
| 1561 | +``` |
|
| 1562 | + |
|
| 1563 | +Because we know R is one less than C, and the R is the one below the top, |
|
| 1564 | +with the C on the top, the value is INCREASED by 1. |
|
| 1565 | + |
|
| 1566 | +If instead we had: |
|
| 1567 | + |
|
| 1568 | +``` |
|
| 1569 | + X R |
|
| 1570 | + -P -G |
|
| 1571 | + = = |
|
| 1572 | + C X |
|
| 1573 | +``` |
|
| 1574 | + |
|
| 1575 | +Because we know R is one less than C, and the C is the one below the top, |
|
| 1576 | +with the R on top, the value is DECREASED by 1. |
|
| 1577 | + |
|
| 1578 | +So, rolling out with known borrow-takes: |
|
| 1579 | + |
|
| 1580 | +``` |
|
| 1581 | + xXx >Cx because R < C, and the larger of the pair is on the top: |
|
| 1582 | + -P -G P + G = base - takes (no takes), PLUS 1 |
|
| 1583 | + = = |
|
| 1584 | + R X |
|
| 1585 | +``` |
|
| 1586 | + |
|
| 1587 | +``` |
|
| 1588 | + xXx >Rx because R < C, and the smaller of the pair is on the top: |
|
| 1589 | + -P -G P + G = base - takes (no takes), MINUS 1 |
|
| 1590 | + = = |
|
| 1591 | + C X |
|
| 1592 | +``` |
|
| 1593 | + |
|
| 1594 | +## SINGLE LETTER SUBTRAHEND DETERMINATION |
|
| 1595 | + |
|
| 1596 | +NOTE: Mostly useful for the "solve4" category of letter division puzzles |
|
| 1597 | +providing a conducive scenario to utilize this strategy. |
|
| 1598 | + |
|
| 1599 | +Let's look at the following puzzle (base 12): |
|
| 1600 | + |
|
| 1601 | +``` |
|
| 1602 | + ???????? |
|
| 1603 | + +--------- |
|
| 1604 | +PTPXQ | NFNXHNXP |
|
| 1605 | + -PTPXQ |
|
| 1606 | + ===== |
|
| 1607 | + EHFXEN |
|
| 1608 | + -EQETEF |
|
| 1609 | + ====== |
|
| 1610 | + EXTXPX |
|
| 1611 | + - PTPXQ |
|
| 1612 | + ====== |
|
| 1613 | + FNJHUP |
|
| 1614 | + -FGHJEP |
|
| 1615 | + ====== |
|
| 1616 | + ?????? |
|
| 1617 | + |
|
| 1618 | +base: 12 |
|
| 1619 | +``` |
|
| 1620 | + |
|
| 1621 | +With a current range of: |
|
| 1622 | + |
|
| 1623 | +``` |
|
| 1624 | + E = { 1, } |
|
| 1625 | + F = { 2, } |
|
| 1626 | + G = { 4, A, } |
|
| 1627 | + H = { 8, } |
|
| 1628 | + J = { 3, } |
|
| 1629 | + N = { B } |
|
| 1630 | + P = { 9, } |
|
| 1631 | + Q = { 7, } |
|
| 1632 | + R = { 4, A, } |
|
| 1633 | + T = { 6, } |
|
| 1634 | + U = { 5, } |
|
| 1635 | + X = { 0, } |
|
| 1636 | +``` |
|
| 1637 | + |
|
| 1638 | +As you can see, we are between G and R for the values of 4 and A. The |
|
| 1639 | +problem here is that R does not appear anywhere in the letter division, |
|
| 1640 | +meaning we have to determine G to determine R. There exists yet another |
|
| 1641 | +problem with G, it only appears as the last subtrahend before an unknown |
|
| 1642 | +remainder; we cannot determine it through natural puzzle-solving means. |
|
| 1643 | + |
|
| 1644 | +There are a few ways to go about this: |
|
| 1645 | + |
|
| 1646 | + * last subtrahend divided by divisor |
|
| 1647 | + * finding largest possible value (with factors of divisor) to subtract last minuend by |
|
| 1648 | + * use the multiplication table and manually carry out the chain of multiplications (propagating carries as generated), building the subtrahend one value at a time (until we reach the letter in question) |
|
| 1649 | + |
|
| 1650 | +Going with the first method is simple, although depending on the values |
|
| 1651 | +known may be impossible or not be as efficient as the second method. We |
|
| 1652 | +start by turning the divisor and last subtrahend into numbers: |
|
| 1653 | + |
|
| 1654 | + * PTPXQ = 96907 |
|
| 1655 | + * FGHJEP = 2G8319 |
|
| 1656 | + |
|
| 1657 | +Since we do not know G yet, we leave it as-is. Now we can substitute G as |
|
| 1658 | +both 4 and A and try dividing by the divisor to see if we get a whole |
|
| 1659 | +number or not: |
|
| 1660 | + |
|
| 1661 | + * 248319 / 96907 = 3 <- Is clearly correct, therefore G is equal to 4 and R is equal to A. |
|
| 1662 | + * 2A8319 / 96907 = 3.76424... |
|
| 1663 | + |
|
| 1664 | +We are done with the first method. Now let's try the second method, which |
|
| 1665 | +requires more work and is very similar, but may come in handy when |
|
| 1666 | +lacking some numbers. First let's start off by turning the divisor and |
|
| 1667 | +last minuend into numbers: |
|
| 1668 | + |
|
| 1669 | + * PTPXQ = 96907 |
|
| 1670 | + * FNJHUP = 2B3859 |
|
| 1671 | + |
|
| 1672 | +Now let's make a factor list for PTPXQ: |
|
| 1673 | + |
|
| 1674 | + * 96907 * 1 = 96907 |
|
| 1675 | + * 96907 * 2 = 171612 |
|
| 1676 | + * 96907 * 3 = 248319 |
|
| 1677 | + * 96907 * 4 = 323024 |
|
| 1678 | + * 96907 * 5 = 3B992B |
|
| 1679 | + * 96907 * 6 = 494636 |
|
| 1680 | + * 96907 * 7 = 56B341 |
|
| 1681 | + * 96907 * 8 = 646048 |
|
| 1682 | + * 96907 * 9 = 720953 |
|
| 1683 | + * 96907 * A = 7B765A |
|
| 1684 | + * 96907 * B = 892365 |
|
| 1685 | + |
|
| 1686 | +From this factor list we need to see the highest number we can subtract |
|
| 1687 | +our last minuend (FNJHUP) by. Clearly 248319 from that group is smaller |
|
| 1688 | +than FNJUP and is the highest possible number. So that is the last |
|
| 1689 | +subtrahend used to get the remainder meaning G is equal 4! |
|
| 1690 | + |
|
| 1691 | +If G is equal to 4 then R is equal to A. |
|
| 1692 | + |
|
| 1693 | +## CHECKING YOUR RESULTS |
|
| 1694 | + |
|
| 1695 | +While things like the solution must be qualitatively evaluated, there are |
|
| 1696 | +a number of simple checks that can be done (especially for your key and |
|
| 1697 | +verify files) to determine whether or not you are on the right path. |
|
| 1698 | + |
|
| 1699 | +On lab46, you can run the **pzlchk** tool in the directory where your |
|
| 1700 | +puzzle files reside, and it will perform a number of tests, reporting its |
|
| 1701 | +findings to you in color-coded fashion. |
|
| 1702 | + |
|
| 1703 | +To use it: |
|
| 1704 | + |
|
| 1705 | + * log into lab46 |
|
| 1706 | + * change into the directory where your pctX.puzzle files are located (key, solution, verify) |
|
| 1707 | + * run the **pzlchk** tool with the appropriate arguments: |
|
| 1708 | + * first argument is your class DESIG |
|
| 1709 | + * second argument is your pctX project |
|
| 1710 | + * analyze the results: |
|
| 1711 | + * green and cyan indicates a level of acceptable status or success |
|
| 1712 | + * red indicates an error |
|
| 1713 | + |
|
| 1714 | +``` |
|
| 1715 | +lab46:~/src/SEMESTER/DESIG/pctX$ pzlchk DESIG pctX |
|
| 1716 | +``` |
|
| 1717 | + |
|
| 1718 | +For example, here's what a fully working, submitted output would look like: |
|
| 1719 | + |
|
| 1720 | +``` |
|
| 1721 | +lab46:~/src/SEMESTER/DESIG/pctX$ pzlchk DESIG pctX |
|
| 1722 | +Checking DESIG/pctX data files ... |
|
| 1723 | + > checking key file ... |
|
| 1724 | + > key file exists: pctX.puzzle.key |
|
| 1725 | + > key is of correct format |
|
| 1726 | + > key is of correct length |
|
| 1727 | + > key matches an entry in the MANIFEST |
|
| 1728 | + > checking solution file ... |
|
| 1729 | + > solution file exists: pctX.puzzle.solution |
|
| 1730 | + > solution file meets minimum length requirements |
|
| 1731 | + > checking verify file ... |
|
| 1732 | + > verify file exists: pctX.puzzle.verify |
|
| 1733 | + > verify is NOT of incorrect format |
|
| 1734 | + |
|
| 1735 | +Checking DESIG/pctX submission ... submitted on 20210202-211205 |
|
| 1736 | +``` |
|
| 1737 | + |
|
| 1738 | +## SUBMISSION |
|
| 1739 | + |
|
| 1740 | +By successfully performing this project, you should be submitting files |
|
| 1741 | +that satisfy the following requirements: |
|
| 1742 | + |
|
| 1743 | + * a `pctX.puzzle.key` file formatted as indicated elsewhere in this project document |
|
| 1744 | + * a `pctX.puzzle.solution` file containing organized and informative detailing of your path to solution |
|
| 1745 | + * a `pctX.puzzle.verify` file containing the appropriate verification information |
|
| 1746 | + |
|
| 1747 | +NOTE: Please substitute the actual project number in place of the 'X' in |
|
| 1748 | +pctX. |
|
| 1749 | + |
|
| 1750 | +To submit this project to me using the **submit** tool, run the following |
|
| 1751 | +command at your lab46 prompt: |
|
| 1752 | + |
|
| 1753 | +``` |
|
| 1754 | +lab46:~/src/SEMESTER/DESIG/pctX$ submit DESIG pctX pctX.puzzle.key pctX.puzzle.solution pctX.puzzle.verify |
|
| 1755 | +Submitting DESIG project "pctX": |
|
| 1756 | + -> pctX.puzzle.key(OK) |
|
| 1757 | + -> pctX.puzzle.solution(OK) |
|
| 1758 | + -> pctX.puzzle.verify(OK) |
|
| 1759 | + |
|
| 1760 | +SUCCESSFULLY SUBMITTED |
|
| 1761 | +``` |
|
| 1762 | + |
|
| 1763 | +NOTE: "DESIG" here is your class designation. It can be something like |
|
| 1764 | +"cprog", "unix", "data", "discrete", "c4eng". You should know what your |
|
| 1765 | +particular class designation is and substitute it into the submit line |
|
| 1766 | +above. |
|
| 1767 | + |
|
| 1768 | +You should get some sort of confirmation indicating successful submission |
|
| 1769 | +if all went according to plan. If not, check for typos and or locational |
|
| 1770 | +mismatches. |
|
| 1771 | + |
|
| 1772 | +I'll be looking for the following: |
|
| 1773 | + |
|
| 1774 | +``` |
|
| 1775 | +XX:pctX:final tally of results (XX/XX) |
|
| 1776 | +*:pctX:puzzle.key file submitted with correct values [#/#] (lower half of one-third) |
|
| 1777 | +*:pctX:puzzle.solution documents discovery of each letter [#/#] (two-thirds) |
|
| 1778 | +*:pctX:puzzle.verify provides verification information [#/#] (upper half of one-third) |
|
| 1779 | +``` |
|
| 1780 | + |
|
| 1781 | +Additional points of consideration: |
|
| 1782 | + |
|
| 1783 | + * if any restrictions are in force and they are ignored in the solving of the problem, up to 50% of credit can be deducted. |
|
| 1784 | + * if solution is messy and disorganized, up to 50% of credit can be deducted (if I cannot easily tell how you got something). |
|
| 1785 | + |
|
| 1786 | +Point values for the various iterations of pctX projects: |
|
| 1787 | + |
|
| 1788 | +| pct0 | 13 pts | bonus | |
|
| 1789 | +| pct1 | 13 pts | bonus | |
|
| 1790 | +| pct2 | 26 pts | | |
|
| 1791 | +| pct3 | 26 pts | bonus | |
|
| 1792 | +| pct4 | 26 pts | | |
|
| 1793 | +| pct5 | 39 pts | bonus | |
|
| 1794 | +| pct6 | 39 pts | | |
|
| 1795 | +| pct7 | 39 pts | bonus | |
|
| 1796 | +| pct8 | 39 pts | | |
|
| 1797 | +| pct9 | 52 pts | bonus | |
|
| 1798 | +| pctA | 52 pts | | |
|
| 1799 | +| pctB | 52 pts | bonus | |
|
| 1800 | +| pctC | 52 pts | | |
|
| 1801 | +| pctD | 52 pts | bonus | |
|
| 1802 | +| pctE | 52 pts | bonus | |
|
| 1803 | +| bwp1 | 39 pts | bonus | |
|
| 1804 | +| bwp2 | 52 pts | bonus | |
haas/fall2026/common/projects/wcpX.md
| ... | ... | @@ -0,0 +1,153 @@ |
| 1 | +# WEEKLY CLASS PARTICIPATION (WCPX) |
|
| 2 | + |
|
| 3 | +## OVERVIEW |
|
| 4 | + |
|
| 5 | +Each week, you have the ability to earn class participation credit by |
|
| 6 | +performing any of the available activities (for some amount of points) |
|
| 7 | +per week within the stated constraints, in order to attain a given point |
|
| 8 | +threshold (varying from week to week or as a general progression |
|
| 9 | +throughout the semester). |
|
| 10 | + |
|
| 11 | +## BACKGROUND |
|
| 12 | + |
|
| 13 | +Measuring participation fulfills a vital role of gauging individual |
|
| 14 | +involvement and interactivity in on-going class activities, not just |
|
| 15 | +their ability to perform assigned projects. |
|
| 16 | + |
|
| 17 | +Being exposed to and interacting with the subject matter helps to improve |
|
| 18 | +understanding, and eventually fluency, yet the trends these days seem to |
|
| 19 | +involve more and more people only putting forth effort for a class DURING |
|
| 20 | +said class (often at the expense of the actual in-class activity going |
|
| 21 | +on). |
|
| 22 | + |
|
| 23 | +Some may think it is time well spent, but when I find myself constantly |
|
| 24 | +repeating myself days, weeks, even months later, it is clear that |
|
| 25 | +something needs to be done in order to improve individual participation |
|
| 26 | +in the course. |
|
| 27 | + |
|
| 28 | +## PARTICIPATION ACTIVITIES |
|
| 29 | + |
|
| 30 | +The following are a list of available activities, along with current |
|
| 31 | +weekly claim caps, and point values that you can perform for |
|
| 32 | +participation credit in a given week. |
|
| 33 | + |
|
| 34 | +Watch this space, as new activities may be added, or old ones obsoleted |
|
| 35 | +(either conditionally or entirely), along with tweaks to claim caps and |
|
| 36 | +point values. |
|
| 37 | + |
|
| 38 | +| attribute | description | cap | points per | week available | |
|
| 39 | +| --------- | --------------------------- | --- | ---------- | -------------- | |
|
| 40 | +| discord# | active on class discord | 6 | 2pts | 1+ | |
|
| 41 | +| early | early submission (3+ days) | 1 | 2pts | 1+ | |
|
| 42 | +| repo | 4+ commits to repository | 1 | 2pts | 1+ | |
|
| 43 | +| present# | physically present | 2 | 1pts | 7+ | |
|
| 44 | + |
|
| 45 | +You will see that, in a normal week a TOTAL of 16-18 points are possible |
|
| 46 | +(depending on particular attribute criteria) |
|
| 47 | + |
|
| 48 | +Each week I will require some subset of the above-stated activities to be |
|
| 49 | +done for participation, giving you choices on how you'd like to earn this |
|
| 50 | +credit. Depending on the combination, I may consider participation |
|
| 51 | +activities done in excess of the weekly cap as some form of bonus |
|
| 52 | +(applied to the participation component). |
|
| 53 | + |
|
| 54 | +NOTE: The eligibility for claiming a `discord#` attribute is based on |
|
| 55 | +on-topic, on-going interactions on the class discord channels. Direct |
|
| 56 | +Messages in Discord do NOT count. |
|
| 57 | + |
|
| 58 | +E-mails do NOT count toward participation. |
|
| 59 | + |
|
| 60 | +Part of your responsibility in the class is to participate in the |
|
| 61 | +learning environment with others. |
|
| 62 | + |
|
| 63 | +During week 1, since we are just getting started, `#generalchat` messages |
|
| 64 | +will be included in the list of acceptable participation sources (but |
|
| 65 | +will only be included for consideration in the first week). |
|
| 66 | + |
|
| 67 | +Pertinent interactions on `#puzzl-y-tastic` will also count towards |
|
| 68 | +acceptable participation sources. |
|
| 69 | + |
|
| 70 | +Cap on bonus points: one can only earn AT MOST HALF the stated weekly |
|
| 71 | +points in bonus form (or 2, if the halfway value is less than 2). |
|
| 72 | + |
|
| 73 | +For `#discord`, the time threshold between earnable points starts at 192 |
|
| 74 | +minutes, and will increment by 192 with each passing earned attribute |
|
| 75 | +throughout the given week. |
|
| 76 | + |
|
| 77 | +Only posts (or accumulations of posts) of at least 32 words will be |
|
| 78 | +considered eligible. Accumulated triggers will only come to fruition once |
|
| 79 | +the necessary time lapse has transpired. |
|
| 80 | + |
|
| 81 | +wcp activity analysis is automated: the **wcp** tool will show you a |
|
| 82 | +daily report of what you've currently accumulated (updated once per day, |
|
| 83 | +sometime around midnight). |
|
| 84 | + |
|
| 85 | +## WCPX REPORTS |
|
| 86 | + |
|
| 87 | +Each week there will be a `wcp#` report started for you to view your |
|
| 88 | +accumulated participation credit, which can be viewed using the `wcp` |
|
| 89 | +tool (on lab46). |
|
| 90 | + |
|
| 91 | +Failure to adequately participate under the terms of the available |
|
| 92 | +attributes by the deadline will result in lost credit: remembering and |
|
| 93 | +time management are important skills as well! |
|
| 94 | + |
|
| 95 | +The report will start on Thursday, and close by the end of that week |
|
| 96 | +Wednesday. You have between the open and close of a reporting period to |
|
| 97 | +perform your recognized participation activities. |
|
| 98 | + |
|
| 99 | +## WEEKLY POINT REQUIREMENTS |
|
| 100 | + |
|
| 101 | +Following will be a list of participation point tallies you will need to |
|
| 102 | +accumulate in a given week to get full credit: |
|
| 103 | + |
|
| 104 | +| week | report | opens on | closes | total points needed | |
|
| 105 | +| NUM | NAME | | on | | |
|
| 106 | +| ---- | ------ | -------- | -------- | ------------------- | |
|
| 107 | +| 1 | `wcp1` | 20260122 | 20260128 | 2 | |
|
| 108 | +| 2 | `wcp2` | 20260129 | 20260204 | 2 | |
|
| 109 | +| 3 | `wcp3` | 20260205 | 20260211 | 4 | |
|
| 110 | +| 4 | `wcp4` | 20260212 | 20260218 | 4 | |
|
| 111 | +| 5 | `wcp5` | 20260219 | 20260225 | 4 | |
|
| 112 | +| 6 | `wcp6` | 20260226 | 20260304 | 4 | |
|
| 113 | +| 7 | `wcp7` | 20260305 | 20260311 | 8 | |
|
| 114 | +| 8 | `wcp8` | 20260312 | 20260325 | 8 | |
|
| 115 | +| 9 | `wcp9` | 20260326 | 20260401 | 8 | |
|
| 116 | +| A | `wcpA` | 20260402 | 20260408 | 8 | |
|
| 117 | +| B | `wcpB` | 20260409 | 20260415 | 8 | |
|
| 118 | +| C | `wcpC` | 20260416 | 20260422 | 8 | |
|
| 119 | +| D | `wcpD` | 20260423 | 20260429 | 8 | |
|
| 120 | +| E | `wcpE` | 20260430 | 20260506 | 8 | |
|
| 121 | + |
|
| 122 | +There are no make-ups. If you miss performing an activity, you can either |
|
| 123 | +make up the credit by other participation activities, or even make up for |
|
| 124 | +lost credit with bonus points in other weeks. |
|
| 125 | + |
|
| 126 | +## VIEWING YOUR CURRENT WEEK PARTICIPATION REPORT |
|
| 127 | + |
|
| 128 | +The sanctioned participation activities, when performed, leave a digital |
|
| 129 | +trail, which I capture. |
|
| 130 | + |
|
| 131 | +The spirit of this activity is that you are making genuine and honest |
|
| 132 | +contributions to participation each and every week. |
|
| 133 | + |
|
| 134 | +### USING WCP |
|
| 135 | + |
|
| 136 | +If you are within the report window for a particular week (say, week1, so |
|
| 137 | +the `wcp1` participation report is active), you can view your report |
|
| 138 | +using the `wcp` tool. |
|
| 139 | + |
|
| 140 | +It takes 2 arguments: |
|
| 141 | + |
|
| 142 | + * the class `DESIG` you are checking the report on (eg: `c4eng`, `cprog`, `unix`) |
|
| 143 | + * the wcpNUM report name (where NUM is `1` for wcp1/week1) |
|
| 144 | + |
|
| 145 | +And you can do so as follows (replace 'DESIG' with your lowercase class |
|
| 146 | +designation, for the appropriate week): |
|
| 147 | + |
|
| 148 | +``` |
|
| 149 | +lab46:~$ wcp DESIG wcpNUM |
|
| 150 | +``` |
|
| 151 | + |
|
| 152 | +This should bring up the current report, displayed to STDOUT in your |
|
| 153 | +lab46 terminal. |
haas/fall2026/comporg/projects/btt0.md
| ... | ... | @@ -0,0 +1,63 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: btt0 |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Our explorations this semester will target the `Vircon32` fantasy |
|
| 8 | +console, an Open Source 32-bit emulator with development toolchain. |
|
| 9 | + |
|
| 10 | +The purpose of this project is to ensure everyone in the class gets the |
|
| 11 | +latest version of `Vircon32` built, installed, and running on their local |
|
| 12 | +development system. |
|
| 13 | + |
|
| 14 | +## REFERENCE |
|
| 15 | + |
|
| 16 | +Be sure to check out the [Vircon32 Assembly Reference](https://github.com/g7n-org/v32ref), especially its [Internet Resources](https://github.com/g7n-org/v32ref?tab=readme-ov-file#internet-resources) section to facilitate finding the needed `Vircon32` archives. |
|
| 17 | + |
|
| 18 | +## TASK |
|
| 19 | + |
|
| 20 | +Download the latest SOURCE CODE release of the `Vircon32` |
|
| 21 | +**ComputerSoftware** repository (latest version as of writing is |
|
| 22 | +**v25.10.29**). Either grab that (or any newer release), or clone the |
|
| 23 | +**ComputerSoftware.git** repository (which should be as new or newer than |
|
| 24 | +the latest release). |
|
| 25 | + |
|
| 26 | +NOTE: If you are running a release OLDER than **v25.10.29** you will want |
|
| 27 | +to update, as there were some important bugs resolved and updates with |
|
| 28 | +this release. |
|
| 29 | + |
|
| 30 | +Please do **NOT** place the `Vircon32` SOURCE CODE in any of existing |
|
| 31 | +repository (not your SEMESTER repo, not the class repo). Place it |
|
| 32 | +someplace entirely independent of version control. |
|
| 33 | + |
|
| 34 | +Reading the provided `README`, go through the build process (installing |
|
| 35 | +any needed supporting packages) to build `Vircon32` FROM SOURCE and then |
|
| 36 | +INSTALL it on your local system. |
|
| 37 | + |
|
| 38 | +Once you have a working, installed `Vircon32` (**DesktopEmulator** AND |
|
| 39 | +**DevTools**), grab the "Hello, World!" C example available on lab46 as a |
|
| 40 | +grabit, and test things out (build it, run the cartridge, verify it all |
|
| 41 | +works). |
|
| 42 | + |
|
| 43 | +Then, modify that "Hello, World!" C program in some meaningful way, |
|
| 44 | +verify it still builds, runs, and works as expected. |
|
| 45 | + |
|
| 46 | +You will be submitting that `C` SOURCE file, the supporting `XML` file, |
|
| 47 | +along with the built `v32` cartridge file. |
|
| 48 | + |
|
| 49 | +### SUBMISSION CRITERIA |
|
| 50 | + |
|
| 51 | +``` |
|
| 52 | +52:btt0:final tally of results (52/52) |
|
| 53 | +*:btt0:grabit of project files before Sunday prior to due date [13/13] |
|
| 54 | +*:btt0:adequate modification of source code beyond default state [13/13] |
|
| 55 | +*:btt0:code compiles cleanly, cartridge builds with no errors [13/13] |
|
| 56 | +*:btt0:the C SOURCE, XML, and v32 cartridge files submitted [13/13] |
|
| 57 | +``` |
|
| 58 | + |
|
| 59 | +Additionally: |
|
| 60 | + * Solutions not abiding by spirit of project will be subject to a 25% overall deduction |
|
| 61 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 62 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 63 | + * 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 |
haas/fall2026/comporg/projects/dap0.md
| ... | ... | @@ -0,0 +1,100 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: DEBUG A PROGRAM (dap0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Create a simple debugging output routine to help investigate issues in |
|
| 8 | +program logic. |
|
| 9 | + |
|
| 10 | +## TASK |
|
| 11 | + |
|
| 12 | +Implement a Vircon32 assembly subroutines that displays the 32-bit |
|
| 13 | +hexadecimal value of an indicated item to the display at a provided set |
|
| 14 | +of coordinates (supplied via the stack). |
|
| 15 | + |
|
| 16 | +Specifically, you want to call the subroutine **`_debug`**, and place it |
|
| 17 | +in a file called **`debug.s`** so that you can **`%include`** it as |
|
| 18 | +needed in your debugging efforts. |
|
| 19 | + |
|
| 20 | +It is written entirely in Vircon32 assembly language, using no |
|
| 21 | +compiler-generated routines from the Vircon32 API (no **print**, no |
|
| 22 | +**itoa**)- you want to create whatever supporting routines are needed. |
|
| 23 | + |
|
| 24 | +Pass 3 parameters via the stack: |
|
| 25 | + |
|
| 26 | + * value to display (first added) |
|
| 27 | + * X coordinate (second added) |
|
| 28 | + * Y coordinate (third added) |
|
| 29 | + |
|
| 30 | +Be sure to preserve all register and important system states (ie whatever |
|
| 31 | +was going on before the call to debug must be preserved: save and |
|
| 32 | +restore) |
|
| 33 | + |
|
| 34 | +Make use of the stack instructions **PUSH** and **POP**, although all |
|
| 35 | +stack access does not have to exclusively be via **PUSH** and **POP**. |
|
| 36 | + |
|
| 37 | +Utilize bitwise logic in the process to convert each nibble of data into |
|
| 38 | +the value/region you will display |
|
| 39 | + |
|
| 40 | +Try it out on some existing code, posting a screenshot (with context) to |
|
| 41 | +the class discord. |
|
| 42 | + |
|
| 43 | +Provide usage instructions (what needs to be added to existing code to |
|
| 44 | +use your debug subroutine) |
|
| 45 | + |
|
| 46 | +## SUBMISSION |
|
| 47 | + |
|
| 48 | +To be successful in this project, the following criteria (or their |
|
| 49 | +equivalent) must be met: |
|
| 50 | + |
|
| 51 | + * Project must be submit on time, by the deadline. |
|
| 52 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 53 | + * Processing must be correct based on input given and output requested |
|
| 54 | + * Output, if applicable, must be correct based on values input |
|
| 55 | + * Code must be nicely and consistently indented and aligned |
|
| 56 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 57 | + * Code must be commented |
|
| 58 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 59 | + * Track/version the source code in your private semester repository |
|
| 60 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 61 | + |
|
| 62 | +## SUBMIT TOOL USAGE |
|
| 63 | + |
|
| 64 | +Let's say you have completed work on the project, and are ready to |
|
| 65 | +submit, you would do the following (once on LAB46, with all your data |
|
| 66 | +present): |
|
| 67 | + |
|
| 68 | +``` |
|
| 69 | +lab46:~/src/SEMESTER/comporg/dap0$ make submit |
|
| 70 | +``` |
|
| 71 | + |
|
| 72 | +You should get some sort of confirmation indicating successful submission |
|
| 73 | +if all went according to plan. If not, check for typos and or locational |
|
| 74 | +mismatches. |
|
| 75 | + |
|
| 76 | +### RUBRIC |
|
| 77 | + |
|
| 78 | +I'll be evaluating the project based on the following criteria: |
|
| 79 | + |
|
| 80 | +``` |
|
| 81 | +182:dap0:final tally of results (182/182) |
|
| 82 | +*:dap0:submitted file called debug.s or debug.asm [13/13] |
|
| 83 | +*:dap0:subroutine is called _debug or __debug [13/13] |
|
| 84 | +*:dap0:code assembles with no warnings or errors [13/13] |
|
| 85 | +*:dap0:parameters obtained via the stack [26/26] |
|
| 86 | +*:dap0:register states preserved across call [13/13] |
|
| 87 | +*:dap0:debug subroutine uses the stack [26/26] |
|
| 88 | +*:dap0:process utilizes bitwise logic [26/26] |
|
| 89 | +*:dap0:screenshot of subroutine in action to discord [13/13] |
|
| 90 | +*:dap0:code contains usage instructions in comments [13/13] |
|
| 91 | +*:dap0:output contains display of contents at coordinates [13/13] |
|
| 92 | +*:dap0:functionality is correct and to specifications [13/13] |
|
| 93 | +``` |
|
| 94 | + |
|
| 95 | +### ADDITIONALLY |
|
| 96 | + |
|
| 97 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 98 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 99 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 100 | + * 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 |
haas/fall2026/comporg/projects/dap1.md
| ... | ... | @@ -0,0 +1,106 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: DEBUG A PROGRAM (dap1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Extend our debugging infrastructure with the creation of a |
|
| 8 | +**`_debugmemory`** subroutine. |
|
| 9 | + |
|
| 10 | +## TASK |
|
| 11 | + |
|
| 12 | +Implement a Vircon32 assembly subroutine that uses your dap0 **`_debug`** |
|
| 13 | +subroutine. Your task is to display a range of memory addresses, along |
|
| 14 | +with their hexadecimal contents. |
|
| 15 | + |
|
| 16 | +The starting and ending memory addresses are given as parameters via the |
|
| 17 | +stack. |
|
| 18 | + |
|
| 19 | +Specifically, you want to call the subroutine **`_debugmemory`**, and |
|
| 20 | +place it in your existing **debug.s** file so that both can be |
|
| 21 | +**%include**'ed as needed in debugging efforts. |
|
| 22 | + |
|
| 23 | +It will call **`_debug`** in the process of operation (let **`_debug`** |
|
| 24 | +handle the display of information) |
|
| 25 | + |
|
| 26 | +Of course: written entirely in Vircon32 assembly language, using no |
|
| 27 | +compiler-generated routines from the Vircon32 API (no **print**, no |
|
| 28 | +**itoa**, only the routines YOU write) |
|
| 29 | + |
|
| 30 | +You will pass 2 parameters via the stack: |
|
| 31 | + |
|
| 32 | + * starting address (first pushed) |
|
| 33 | + * ending address (second pushed) |
|
| 34 | + |
|
| 35 | +You want to make sure all register states preserved (ie whatever was |
|
| 36 | +going on before the call to debug must be preserved: save and restore) |
|
| 37 | + |
|
| 38 | +Make use of the stack instructions **PUSH** and **POP**, although all |
|
| 39 | +stack access does not have to exclusively be via **PUSH** and **POP** |
|
| 40 | + |
|
| 41 | +Try it out on some existing code, posting a screenshot (with context) to |
|
| 42 | +the class discord |
|
| 43 | + |
|
| 44 | +In your code (via comments), provide usage instructions (what needs to be |
|
| 45 | +added to existing code to use your debug subroutine) |
|
| 46 | + |
|
| 47 | +Modify **`_debug`** to "return" an updated X and Y coordinate (by |
|
| 48 | +updating the value stored in the stack), so that **_debugmemory** can |
|
| 49 | +**POP** and use it in its own processes. |
|
| 50 | + |
|
| 51 | +Make sure to display any leading zeros in your output. |
|
| 52 | + |
|
| 53 | +## SUBMISSION |
|
| 54 | + |
|
| 55 | +To be successful in this project, the following criteria (or their |
|
| 56 | +equivalent) must be met: |
|
| 57 | + |
|
| 58 | + * Project must be submit on time, by the deadline. |
|
| 59 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 60 | + * Processing must be correct based on input given and output requested |
|
| 61 | + * Output, if applicable, must be correct based on values input |
|
| 62 | + * Code must be nicely and consistently indented and aligned |
|
| 63 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 64 | + * Code must be commented |
|
| 65 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 66 | + * Track/version the source code in your private semester repository |
|
| 67 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 68 | + |
|
| 69 | +## SUBMIT TOOL USAGE |
|
| 70 | + |
|
| 71 | +Let's say you have completed work on the project, and are ready to |
|
| 72 | +submit, you would do the following (once on LAB46, with all your data |
|
| 73 | +present): |
|
| 74 | + |
|
| 75 | +``` |
|
| 76 | +lab46:~/src/SEMESTER/comporg/dap1$ make submit |
|
| 77 | +``` |
|
| 78 | + |
|
| 79 | +You should get some sort of confirmation indicating successful submission |
|
| 80 | +if all went according to plan. If not, check for typos and or locational |
|
| 81 | +mismatches. |
|
| 82 | + |
|
| 83 | +### RUBRIC |
|
| 84 | + |
|
| 85 | +I'll be evaluating the project based on the following criteria: |
|
| 86 | + |
|
| 87 | +``` |
|
| 88 | +234:dap1:final tally of results (234/234) |
|
| 89 | +*:dap1:submitted file called debug.s or debug.asm [13/13] |
|
| 90 | +*:dap1:subroutine is called _debugmemory or __debugmemory [13/13] |
|
| 91 | +*:dap1:code assembles with no warnings or errors [26/26] |
|
| 92 | +*:dap1:parameters obtained, modified in the stack [26/26] |
|
| 93 | +*:dap1:register states preserved across call [26/26] |
|
| 94 | +*:dap1:debugging subroutines use stack instructions [26/26] |
|
| 95 | +*:dap1:screenshot of subroutine in action to DISCORD [26/26] |
|
| 96 | +*:dap1:code contains usage instructions in comments [26/26] |
|
| 97 | +*:dap1:output contains display of addresses, contents [26/26] |
|
| 98 | +*:dap1:functionality is correct and to specifications [26/26] |
|
| 99 | +``` |
|
| 100 | + |
|
| 101 | +### ADDITIONALLY |
|
| 102 | + |
|
| 103 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 104 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 105 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 106 | + * 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 |
haas/fall2026/comporg/projects/dap2.md
| ... | ... | @@ -0,0 +1,97 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: DEBUG A PROGRAM (dap2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Extend our debugging infrastructure with the creation of a |
|
| 8 | +**`debugregs`** subroutine. |
|
| 9 | + |
|
| 10 | +## TASK |
|
| 11 | + |
|
| 12 | +Implement a Vircon32 assembly subroutine that uses your dap0 routine. |
|
| 13 | +subroutine. Your task is to display the set of CPU registers (R0-R13), |
|
| 14 | +along with their hexadecimal contents. |
|
| 15 | + |
|
| 16 | +No parameters need to be given to this debugging subroutine, since it |
|
| 17 | +will always be displaying this same range of registers. |
|
| 18 | + |
|
| 19 | +Specifically, be sure to: |
|
| 20 | + |
|
| 21 | +... call the subroutine **`debugregs`** or **`_debugregisters`**, and |
|
| 22 | +place it in your existing **debug.s** file so that both (and also |
|
| 23 | +**_debugmemory** from dap1) can be **%include**'ed as needed in debugging |
|
| 24 | +efforts. |
|
| 25 | + |
|
| 26 | +Make sure it that it calls and makes use of your original **_debug** |
|
| 27 | +in the process of operation (let **_debug** handle the display of |
|
| 28 | +information). |
|
| 29 | + |
|
| 30 | +That it is written entirely in Vircon32 assembly language, using no |
|
| 31 | +compiler-generated routines from the Vircon32 API (no **print**, no |
|
| 32 | +**itoa**) |
|
| 33 | + |
|
| 34 | +As stated above: no parameters need to be passed in to use this routine. |
|
| 35 | + |
|
| 36 | +Pertaining to the registers, make sure your routine preserves existing |
|
| 37 | +register states, so that whatever was going on before the call to debug |
|
| 38 | +is saved, so you can restore it upon completion). |
|
| 39 | + |
|
| 40 | +Display registers R0-R7 in the left column, starting at or near the top |
|
| 41 | +left of the screen, with R8-R13 in the right column, separated by an |
|
| 42 | +appropriate distance. |
|
| 43 | + |
|
| 44 | +## SUBMISSION |
|
| 45 | + |
|
| 46 | +To be successful in this project, the following criteria (or their |
|
| 47 | +equivalent) must be met: |
|
| 48 | + |
|
| 49 | + * Project must be submit on time, by the deadline. |
|
| 50 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 51 | + * Processing must be correct based on input given and output requested |
|
| 52 | + * Output, if applicable, must be correct based on values input |
|
| 53 | + * Code must be nicely and consistently indented and aligned |
|
| 54 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 55 | + * Code must be commented |
|
| 56 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 57 | + * Track/version the source code in your private semester repository |
|
| 58 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 59 | + |
|
| 60 | +## SUBMIT TOOL USAGE |
|
| 61 | + |
|
| 62 | +Let's say you have completed work on the project, and are ready to |
|
| 63 | +submit, you would do the following (once on LAB46, with all your data |
|
| 64 | +present): |
|
| 65 | + |
|
| 66 | +``` |
|
| 67 | +lab46:~/src/SEMESTER/comporg/dap1$ make submit |
|
| 68 | +``` |
|
| 69 | + |
|
| 70 | +You should get some sort of confirmation indicating successful submission |
|
| 71 | +if all went according to plan. If not, check for typos and or locational |
|
| 72 | +mismatches. |
|
| 73 | + |
|
| 74 | +### RUBRIC |
|
| 75 | + |
|
| 76 | +I'll be evaluating the project based on the following criteria: |
|
| 77 | + |
|
| 78 | +``` |
|
| 79 | +286:dap2:final tally of results (286/286) |
|
| 80 | +*:dap2:submitted file called debug.s or debug.asm [26/26] |
|
| 81 | +*:dap2:subroutine is called _debugregs or __debugregisters [26/26] |
|
| 82 | +*:dap2:code assembles with no warnings or errors [26/26] |
|
| 83 | +*:dap2:register states preserved across call [26/26] |
|
| 84 | +*:dap2:calls upon original _debug to do data output [26/26] |
|
| 85 | +*:dap2:output contains display of registers, contents [52/52] |
|
| 86 | +*:dap2:screenshot of subroutine in action to DISCORD [26/26] |
|
| 87 | +*:dap2:code contains usage instructions in comments [26/26] |
|
| 88 | +*:dap2:output contains display of addresses, contents [26/26] |
|
| 89 | +*:dap2:functionality is correct and to specifications [26/26] |
|
| 90 | +``` |
|
| 91 | + |
|
| 92 | +### ADDITIONALLY |
|
| 93 | + |
|
| 94 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 95 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 96 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 97 | + * 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 |
haas/fall2026/comporg/projects/gamE.md
| ... | ... | @@ -0,0 +1,42 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: GAME SNAPSHOT (gamE) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Snapshot of progress on the EoCE game |
|
| 8 | + |
|
| 9 | +## TASK |
|
| 10 | + |
|
| 11 | +As per the EoCE, we are implementing a game in Vircon32 assembly |
|
| 12 | +language; while the game is not expected to be done by this point, active |
|
| 13 | +participation in its development is to be underway. |
|
| 14 | + |
|
| 15 | +Commits and contributions will be looked at to make sure everyone is |
|
| 16 | +pulling their own weight. |
|
| 17 | + |
|
| 18 | +Having some sort of viewable / playable thing wouldn't hurt (although |
|
| 19 | +that depends on overall development progress). |
|
| 20 | + |
|
| 21 | +## SUBMIT |
|
| 22 | + |
|
| 23 | +While no format submission is necessary, be sure that your repository |
|
| 24 | +activity is such that it can be clearly discerned that you are active and |
|
| 25 | +documenting of your contributions and progress. |
|
| 26 | + |
|
| 27 | +## RUBRIC |
|
| 28 | + |
|
| 29 | +I'll be evaluating the project based on the following criteria: |
|
| 30 | + |
|
| 31 | +``` |
|
| 32 | +312:gamE:final tally of results (312/312) |
|
| 33 | +*:gamE:multiple commits pertaining to the game in class repo [156/156] |
|
| 34 | +*:gamE:contributions documented commit messages [156/156] |
|
| 35 | +``` |
|
| 36 | + |
|
| 37 | +### ADDITIONALLY |
|
| 38 | + |
|
| 39 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 40 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 41 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 42 | + * 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 |
haas/fall2026/comporg/projects/images/pnc0runtime.png
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/pnc0runtime.png differ |
haas/fall2026/comporg/projects/images/pnc0runtime_nocycles.png
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/pnc0runtime_nocycles.png differ |
haas/fall2026/comporg/projects/images/pnc1runtime.png
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/pnc1runtime.png differ |
haas/fall2026/comporg/projects/images/pnc1runtime_nocycles.png
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/pnc1runtime_nocycles.png differ |
haas/fall2026/comporg/projects/images/pnc2runtime.png
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/pnc2runtime.png differ |
haas/fall2026/comporg/projects/images/sieveanimation.gif
| ... | ... | Binary files /dev/null and b/haas/fall2026/comporg/projects/images/sieveanimation.gif differ |
haas/fall2026/comporg/projects/mab0.md
| ... | ... | @@ -0,0 +1,77 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: MOVE A BLOCK (mab0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +This week we turn our attention to starting to write (from scratch) code |
|
| 8 | +in Vircon32 assembly language. |
|
| 9 | + |
|
| 10 | +We will start with the most basic of ingredients: render a block on the |
|
| 11 | +screen, and allow it to move via the gamepad. |
|
| 12 | + |
|
| 13 | +## GRABIT |
|
| 14 | + |
|
| 15 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 16 | +and a Makefile, that will facilitate building the cartridge. |
|
| 17 | + |
|
| 18 | +## TASK |
|
| 19 | + |
|
| 20 | +Implemented from scratch, in assembly: |
|
| 21 | + |
|
| 22 | + * select the loaded texture |
|
| 23 | + * select 4 objects (regions) to display |
|
| 24 | + * display the object on the screen, allowing for its control via the gamepads |
|
| 25 | + * each gamepad direction should display a different object |
|
| 26 | + * implement bounds checks on the screen edges, preventing the object from moving off the screen (or performing a wraparound, as desired) |
|
| 27 | + |
|
| 28 | +## SUBMISSION |
|
| 29 | + |
|
| 30 | +To be successful in this project, the following criteria (or their |
|
| 31 | +equivalent) must be met: |
|
| 32 | + |
|
| 33 | + * Project must be submit on time, by the deadline. |
|
| 34 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 35 | + * Processing must be correct based on input given and output requested |
|
| 36 | + * Output, if applicable, must be correct based on values input |
|
| 37 | + * Code must be nicely and consistently indented and aligned |
|
| 38 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 39 | + * Code must be commented |
|
| 40 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 41 | + * Track/version the source code in your private semester repository |
|
| 42 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 43 | + |
|
| 44 | +## SUBMIT TOOL USAGE |
|
| 45 | + |
|
| 46 | +Let's say you have completed work on the project, and are ready to |
|
| 47 | +submit, you would do the following (once on LAB46, with all your data |
|
| 48 | +present): |
|
| 49 | + |
|
| 50 | +``` |
|
| 51 | +lab46:~/src/SEMESTER/DESIG/mab0$ make submit |
|
| 52 | +``` |
|
| 53 | + |
|
| 54 | +You should get some sort of confirmation indicating successful submission |
|
| 55 | +if all went according to plan. If not, check for typos and or locational |
|
| 56 | +mismatches. |
|
| 57 | + |
|
| 58 | +### RUBRIC |
|
| 59 | + |
|
| 60 | +I'll be evaluating the project based on the following criteria: |
|
| 61 | + |
|
| 62 | +``` |
|
| 63 | +78:mab0:final tally of results (78/78) |
|
| 64 | +*:mab0:code written from scratch in Vircon32 assembly [13/13] |
|
| 65 | +*:mab0:code assembles cleanly, with no warnings [13/13] |
|
| 66 | +*:mab0:submit code, XML file, and v32 cartridge [13/13] |
|
| 67 | +*:mab0:program displays one of four regions based on direction [13/13] |
|
| 68 | +*:mab0:program reads the gamepad to adjust position of region [13/13] |
|
| 69 | +*:mab0:region when encountering screen edge will stop or wrap [13/13] |
|
| 70 | +``` |
|
| 71 | + |
|
| 72 | +### ADDITIONALLY |
|
| 73 | + |
|
| 74 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 75 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 76 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 77 | + * 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 |
haas/fall2026/comporg/projects/mab1.md
| ... | ... | @@ -0,0 +1,81 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: MOVE A BLOCK (mab1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +This week we extend upon our simple block movement program, turning it |
|
| 8 | +into a fully functional one-player `PONG` game, hand-written in Vircon32 |
|
| 9 | +Assembly Language. |
|
| 10 | + |
|
| 11 | +## GRABIT |
|
| 12 | + |
|
| 13 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 14 | +and a Makefile, that will facilitate building the cartridge. |
|
| 15 | + |
|
| 16 | +## TASK |
|
| 17 | + |
|
| 18 | +Implemented from scratch, in assembly: |
|
| 19 | + |
|
| 20 | + * have texture(s), regions for a paddle and a ball |
|
| 21 | + * have the ball rebound, continuing in one direction until it hits a bound |
|
| 22 | + * bounds can be the top, bottom, or side of the screen (which it will reflect off of) |
|
| 23 | + * bounds can also be the paddle (which it will also reflect off of) |
|
| 24 | + * paddle bounds are the edges of the screen (prevent it from getting lost off the screen) |
|
| 25 | + * if the paddle fails to deflect the ball and the ball moves beyond the screen, reset the ball and start again |
|
| 26 | + * display the paddle and ball on the screen, allowing paddle control via the gamepad |
|
| 27 | + * two gamepad directions will be necessary for moving the paddle |
|
| 28 | + * implement a simple scoring system and display |
|
| 29 | + |
|
| 30 | +## SUBMISSION |
|
| 31 | + |
|
| 32 | +To be successful in this project, the following criteria (or their |
|
| 33 | +equivalent) must be met: |
|
| 34 | + |
|
| 35 | + * Project must be submit on time, by the deadline. |
|
| 36 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 37 | + * Processing must be correct based on input given and output requested |
|
| 38 | + * Output, if applicable, must be correct based on values input |
|
| 39 | + * Code must be nicely and consistently indented and aligned |
|
| 40 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 41 | + * Code must be commented |
|
| 42 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 43 | + * Track/version the source code in your private semester repository |
|
| 44 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 45 | + |
|
| 46 | +## SUBMIT TOOL USAGE |
|
| 47 | + |
|
| 48 | +Let's say you have completed work on the project, and are ready to |
|
| 49 | +submit, you would do the following (once on LAB46, with all your data |
|
| 50 | +present): |
|
| 51 | + |
|
| 52 | +``` |
|
| 53 | +lab46:~/src/SEMESTER/DESIG/mab1$ make submit |
|
| 54 | +``` |
|
| 55 | + |
|
| 56 | +You should get some sort of confirmation indicating successful submission |
|
| 57 | +if all went according to plan. If not, check for typos and or locational |
|
| 58 | +mismatches. |
|
| 59 | + |
|
| 60 | +### RUBRIC |
|
| 61 | + |
|
| 62 | +I'll be evaluating the project based on the following criteria: |
|
| 63 | + |
|
| 64 | +``` |
|
| 65 | +104:mab1:final tally of results (104/104) |
|
| 66 | +*:mab1:code assembles cleanly, with no warnings [13/13] |
|
| 67 | +*:mab1:submit code, XML file, and v32 cartridge [13/13] |
|
| 68 | +*:mab1:paddle displays, position adjusted by gamepad [13/13] |
|
| 69 | +*:mab1:paddle is bounded by screen edges [13/13] |
|
| 70 | +*:mab1:paddle can deflect ball [13/13] |
|
| 71 | +*:mab1:ball moves automatically, resets if it goes off screen [13/13] |
|
| 72 | +*:mab1:ball deflects off screen edges [13/13] |
|
| 73 | +*:mab1:game keeps and displays score [13/13] |
|
| 74 | +``` |
|
| 75 | + |
|
| 76 | +### ADDITIONALLY |
|
| 77 | + |
|
| 78 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 79 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 80 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 81 | + * 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 |
haas/fall2026/comporg/projects/mab2.md
| ... | ... | @@ -0,0 +1,94 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: MAKE A BREAKOUT (mab2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Now, take your `PONG` game, and transition it into a `BREAKOUT` game, |
|
| 8 | +where in addition to the paddle and ball, there are bricks present on the |
|
| 9 | +screen (either in rows or some pattern). The ball when colliding with a |
|
| 10 | +brick will rebound off of it (just as if it were a wall or paddle), but |
|
| 11 | +cause the brick to disappear. |
|
| 12 | + |
|
| 13 | +## GRABIT |
|
| 14 | + |
|
| 15 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 16 | +and a Makefile, that will facilitate building the cartridge. |
|
| 17 | + |
|
| 18 | +## TASK |
|
| 19 | + |
|
| 20 | +Implemented from scratch, in assembly: |
|
| 21 | + |
|
| 22 | + * use more than just the BIOS texture for graphics |
|
| 23 | + * have texture(s), regions for a paddle, brick(s), and a ball |
|
| 24 | + * have the ball rebound, continuing in one direction until it hits a bound |
|
| 25 | + * bounds can be the top, bottom, or side of the screen (which it will reflect off of) |
|
| 26 | + * bounds can also be the paddle (which it will also reflect off of) |
|
| 27 | + * bounds can be any of the bricks (which it will reflect off it, causing the brick to disappear) |
|
| 28 | + * paddle bounds are the edges of the screen (prevent it from getting lost off the screen) |
|
| 29 | + * if the paddle fails to deflect the ball and the ball moves beyond the screen, reset the ball and start again |
|
| 30 | + * display the paddle and ball on the screen, allowing paddle control via the gamepad |
|
| 31 | + * two gamepad directions will be necessary for moving the paddle |
|
| 32 | + * display the bricks on the screen, allowing for collision with the ball (if present/visible) |
|
| 33 | + * implement a simple scoring system and display (hitting and destroying a brick) |
|
| 34 | + |
|
| 35 | +Feel free to add some frills: |
|
| 36 | + |
|
| 37 | + * power-ups |
|
| 38 | + * different brick colors |
|
| 39 | + * sound effects (ball hitting paddle/bricks) |
|
| 40 | + |
|
| 41 | +## SUBMISSION |
|
| 42 | + |
|
| 43 | +To be successful in this project, the following criteria (or their |
|
| 44 | +equivalent) must be met: |
|
| 45 | + |
|
| 46 | + * Project must be submit on time, by the deadline. |
|
| 47 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 48 | + * Processing must be correct based on input given and output requested |
|
| 49 | + * Output, if applicable, must be correct based on values input |
|
| 50 | + * Code must be nicely and consistently indented and aligned |
|
| 51 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 52 | + * Code must be commented |
|
| 53 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 54 | + * Track/version the source code in your private semester repository |
|
| 55 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 56 | + |
|
| 57 | +## SUBMIT TOOL USAGE |
|
| 58 | + |
|
| 59 | +Let's say you have completed work on the project, and are ready to |
|
| 60 | +submit, you would do the following (once on LAB46, with all your data |
|
| 61 | +present): |
|
| 62 | + |
|
| 63 | +``` |
|
| 64 | +lab46:~/src/SEMESTER/DESIG/mab2$ make submit |
|
| 65 | +``` |
|
| 66 | + |
|
| 67 | +You should get some sort of confirmation indicating successful submission |
|
| 68 | +if all went according to plan. If not, check for typos and or locational |
|
| 69 | +mismatches. |
|
| 70 | + |
|
| 71 | +### RUBRIC |
|
| 72 | + |
|
| 73 | +I'll be evaluating the project based on the following criteria: |
|
| 74 | + |
|
| 75 | +``` |
|
| 76 | +130:mab2:final tally of results (130/130) |
|
| 77 | +*:mab2:post screenshot or short video of game in class channel [13/13] |
|
| 78 | +*:mab2:code assembles cleanly, with no warnings [13/13] |
|
| 79 | +*:mab2:submit code, XML file, and v32 cartridge [13/13] |
|
| 80 | +*:mab2:paddle displays, position adjusted by gamepad [13/13] |
|
| 81 | +*:mab2:paddle is bounded by screen edges [13/13] |
|
| 82 | +*:mab2:paddle can deflect ball [13/13] |
|
| 83 | +*:mab2:ball moves automatically, resets if it goes off screen [13/13] |
|
| 84 | +*:mab2:ball deflects off screen edges, paddle, or bricks [13/13] |
|
| 85 | +*:mab2:brick disappears upon collision with ball [13/13] |
|
| 86 | +*:mab2:game keeps and displays score [13/13] |
|
| 87 | +``` |
|
| 88 | + |
|
| 89 | +### ADDITIONALLY |
|
| 90 | + |
|
| 91 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 92 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 93 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 94 | + * 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 |
haas/fall2026/comporg/projects/pnc0.md
| ... | ... | @@ -0,0 +1,95 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: PRIME NUMBER COMPUTATIONS (pnc0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Start exploring algorithm/implementation comparison and optimization with |
|
| 8 | +respect to various approaches of computing prime numbers. |
|
| 9 | + |
|
| 10 | +## GRABIT |
|
| 11 | + |
|
| 12 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 13 | +and a Makefile, that will facilitate building the cartridge. |
|
| 14 | + |
|
| 15 | +## TASK |
|
| 16 | + |
|
| 17 | +Implement two separate, independent programs, one in Vircon32 C, and |
|
| 18 | +other in Vircon32 assembly, that: |
|
| 19 | + |
|
| 20 | + * performs a brute force/"trial-by-division" process on a range of values, 2-N |
|
| 21 | + * the values for N are some sufficient quantity still small enough to fit within an integer |
|
| 22 | + * the values for N will have some relationship (powers of 2, powers of 10/magnitudes) that ideally can be computed via some loop/equation (ie 1024, 2048, 4098, 8192, 16384, etc.) |
|
| 23 | + * the values for N have some sufficient quantity large enough where its upper set values will take some amount of time to compute (fast enough to have some relatable value, not to exceed 16 seconds) |
|
| 24 | + * for each value of N: |
|
| 25 | + * display that N/upper bound |
|
| 26 | + * tally: display the number of primes identified (2-N) |
|
| 27 | + * display the amount of time taken to do the total computation for that value of N, out to 3 decimal places |
|
| 28 | + * display each N value and result in an arrangement on the screen that can be clearly identified and read by the viewer |
|
| 29 | + * timing should go out, as reasonable, to a few decimal places, and should be consistent across all attempts. |
|
| 30 | + * timing is on the computational process only, not the display of results. |
|
| 31 | + * create a graph (using some external tool) that plots the performance of the C and assembly implementations working on identical workloads of this brute force algorithm according to the various N's and the time it took. Share your graph of your results on the class discord and on the project documentation page. |
|
| 32 | + * a line graph is the suggested best candidate |
|
| 33 | + * the assembly version is to be done entirely by hand, and make zero use of C API functions. Just the usual in/out stuff we've been doing. |
|
| 34 | + * this will not be an interactive program: it starts up, does its thing, outputs it results, then halts. |
|
| 35 | + * this brute force implementation is meant as our baseline. As such, it should not contain any optimizations or attempted improvements. As we progress through `pnc1` and `pnc2`, this base implementation should be the least efficient. This is important, to allow us to realize the impact of various improvements we will be making in those upcoming projects. |
|
| 36 | + |
|
| 37 | +## REFERENCE |
|
| 38 | + |
|
| 39 | +The following are reference screenshots of what your implementations |
|
| 40 | +should approximate: |
|
| 41 | + |
|
| 42 | +### PNC0 C IMPLEMENTATION |
|
| 43 | + |
|
| 44 | + |
|
| 45 | + |
|
| 46 | +## SUBMISSION |
|
| 47 | + |
|
| 48 | +To be successful in this project, the following criteria (or their |
|
| 49 | +equivalent) must be met: |
|
| 50 | + |
|
| 51 | + * Project must be submit on time, by the deadline. |
|
| 52 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 53 | + * Processing must be correct based on input given and output requested |
|
| 54 | + * Output, if applicable, must be correct based on values input |
|
| 55 | + * Code must be nicely and consistently indented and aligned |
|
| 56 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 57 | + * Code must be commented |
|
| 58 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 59 | + * Track/version the source code in your private semester repository |
|
| 60 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 61 | + |
|
| 62 | +## SUBMIT TOOL USAGE |
|
| 63 | + |
|
| 64 | +Let's say you have completed work on the project, and are ready to |
|
| 65 | +submit, you would do the following (once on LAB46, with all your data |
|
| 66 | +present): |
|
| 67 | + |
|
| 68 | +``` |
|
| 69 | +lab46:~/src/SEMESTER/DESIG/pnc0$ make submit |
|
| 70 | +``` |
|
| 71 | + |
|
| 72 | +You should get some sort of confirmation indicating successful submission |
|
| 73 | +if all went according to plan. If not, check for typos and or locational |
|
| 74 | +mismatches. |
|
| 75 | + |
|
| 76 | +### RUBRIC |
|
| 77 | + |
|
| 78 | +I'll be evaluating the project based on the following criteria: |
|
| 79 | + |
|
| 80 | +``` |
|
| 81 | +156:pnc0:final tally of results (156/156) |
|
| 82 | +*:pnc0:submitted working C and assembly implementations [26/26] |
|
| 83 | +*:pnc0:post screenshots to class DISCORD channel [26/26] |
|
| 84 | +*:pnc0:processing is correct, and to specifications [26/26] |
|
| 85 | +*:pnc0:no optimizations or improvements on the process [26/26] |
|
| 86 | +*:pnc0:graph produced from timing data produced [26/26] |
|
| 87 | +*:pnc0:timing data is taken out to at least 3 decimal places [26/26] |
|
| 88 | +``` |
|
| 89 | + |
|
| 90 | +### ADDITIONALLY |
|
| 91 | + |
|
| 92 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 93 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 94 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 95 | + * 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 |
haas/fall2026/comporg/projects/pnc1.md
| ... | ... | @@ -0,0 +1,97 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: PRIME NUMBER COMPUTATIONS (pnc1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Continue exploring algorithm/implementation comparison and optimization |
|
| 8 | +with respect to various approaches of computing prime numbers. |
|
| 9 | + |
|
| 10 | +## GRABIT |
|
| 11 | + |
|
| 12 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 13 | +and a Makefile, that will facilitate building the cartridge. |
|
| 14 | + |
|
| 15 | +## TASK |
|
| 16 | + |
|
| 17 | +Add to your two separate, independent programs, one in Vircon32 C, and |
|
| 18 | +other in Vircon32 assembly, functionality that: |
|
| 19 | + |
|
| 20 | + * implements functionality for the following optimizations (both in C and assembly): |
|
| 21 | + * break: breaks from trial division/brute force when a viable factor is found (break on composite) |
|
| 22 | + * odds: assuming 2 is prime, does odds-only processing (both number and factor check) |
|
| 23 | + * sqrt: only processes up through the square root point of the number being evaluated |
|
| 24 | + * implementation here include the following: |
|
| 25 | + * break |
|
| 26 | + * odds |
|
| 27 | + * sqrt |
|
| 28 | + * break+odds |
|
| 29 | + * odds+sqrt |
|
| 30 | + * break+sqrt |
|
| 31 | + * break+odds+sqrt |
|
| 32 | + * collects the same timing data with common workloads to the brute force/naive variants from pnc0 |
|
| 33 | + * new variants added to the runtime graph you made in pnc0, adjusting and re-running pnc0 variants to allow for a consistent presentation of information |
|
| 34 | + * be sure to use distinctive colors/patterns to distinguish items on the graph (again, line graph is a recommended choice) |
|
| 35 | + |
|
| 36 | +## REFERENCE |
|
| 37 | + |
|
| 38 | +The following are reference screenshots of what your implementations |
|
| 39 | +should approximate: |
|
| 40 | + |
|
| 41 | +### PNC1 C IMPLEMENTATION |
|
| 42 | + |
|
| 43 | + |
|
| 44 | + |
|
| 45 | +## SUBMISSION |
|
| 46 | + |
|
| 47 | +To be successful in this project, the following criteria (or their |
|
| 48 | +equivalent) must be met: |
|
| 49 | + |
|
| 50 | + * Project must be submit on time, by the deadline. |
|
| 51 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 52 | + * Processing must be correct based on input given and output requested |
|
| 53 | + * Output, if applicable, must be correct based on values input |
|
| 54 | + * Code must be nicely and consistently indented and aligned |
|
| 55 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 56 | + * Code must be commented |
|
| 57 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 58 | + * Track/version the source code in your private semester repository |
|
| 59 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 60 | + |
|
| 61 | +## SUBMIT TOOL USAGE |
|
| 62 | + |
|
| 63 | +Let's say you have completed work on the project, and are ready to |
|
| 64 | +submit, you would do the following (once on LAB46, with all your data |
|
| 65 | +present): |
|
| 66 | + |
|
| 67 | +``` |
|
| 68 | +lab46:~/src/SEMESTER/DESIG/pnc1$ make submit |
|
| 69 | +``` |
|
| 70 | + |
|
| 71 | +You should get some sort of confirmation indicating successful submission |
|
| 72 | +if all went according to plan. If not, check for typos and or locational |
|
| 73 | +mismatches. |
|
| 74 | + |
|
| 75 | +### RUBRIC |
|
| 76 | + |
|
| 77 | +I'll be evaluating the project based on the following criteria: |
|
| 78 | + |
|
| 79 | +``` |
|
| 80 | +208:pnc1:final tally of results (208/208) |
|
| 81 | +*:pnc1:submitted working C and assembly implementations [13/13] |
|
| 82 | +*:pnc1:graph produced from timing data produced [26/26] |
|
| 83 | +*:pnc1:post screenshots to class DISCORD channel [26/26] |
|
| 84 | +*:pnc1:processing is correct, and to specifications [26/26] |
|
| 85 | +*:pnc1:working break on composite optimization [26/26] |
|
| 86 | +*:pnc1:working odds only processing optimization [26/26] |
|
| 87 | +*:pnc1:working sqrt factor cap optimization [26/26] |
|
| 88 | +*:pnc1:all variants and combinations thereof operational [26/26] |
|
| 89 | +*:pnc1:timing data is taken out to at least 4 decimal places [13/13] |
|
| 90 | +``` |
|
| 91 | + |
|
| 92 | +### ADDITIONALLY |
|
| 93 | + |
|
| 94 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 95 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 96 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 97 | + * 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 |
haas/fall2026/comporg/projects/pnc2.md
| ... | ... | @@ -0,0 +1,113 @@ |
| 1 | +# CSCS2650 Computer Organization |
|
| 2 | + |
|
| 3 | +# PROJECT: PRIME NUMBER COMPUTATIONS (pnc2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Continue exploring algorithm/implementation, this time exploring a new |
|
| 8 | +algorithm: the sieve of eratosthenes and selected optimization. |
|
| 9 | + |
|
| 10 | +## GRABIT |
|
| 11 | + |
|
| 12 | +There is a GRABIT available, containing some skeleton code, an XML file, |
|
| 13 | +and a Makefile, that will facilitate building the cartridge. |
|
| 14 | + |
|
| 15 | +## TASK |
|
| 16 | + |
|
| 17 | +Add to your two separate, independent programs, one in Vircon32 C, and |
|
| 18 | +other in Vircon32 assembly, functionality that implements the following: |
|
| 19 | + |
|
| 20 | + * sieve of eratosthenes (soe) |
|
| 21 | + * sieve of eratosthenes with sqrt optimization (soe +s) |
|
| 22 | + |
|
| 23 | +Collect the timing data and add them onto your graphs. NOTE that you may |
|
| 24 | +have to adjust your bounds, and if needed, drop the naive brute |
|
| 25 | +implementation from consideration due to the extreme gap in performance. |
|
| 26 | + |
|
| 27 | +## PROGRAM |
|
| 28 | + |
|
| 29 | +Your next program, and first sieve, will be the Sieve of Eratosthenes. |
|
| 30 | +Perhaps among the best and likely longest-known sieves, its origins date |
|
| 31 | +from antiquity. |
|
| 32 | + |
|
| 33 | +This sieve, instead of calculating to determine the eligibility of a |
|
| 34 | +prime, works in a manner of marking off patterns of values that cannot be |
|
| 35 | +prime (so, it is composite-focused in approach vs. prime-focused). |
|
| 36 | + |
|
| 37 | +In order for it to work, we must store all the values we're processing so |
|
| 38 | +we can obtain what is left when done– what remains are the prime |
|
| 39 | +values. |
|
| 40 | + |
|
| 41 | +Some refined considerations: |
|
| 42 | + |
|
| 43 | + * include memory management related to the sieve in your timing |
|
| 44 | + * take measurements out to FIVE (5) decimal places |
|
| 45 | + * consider doing a bar graph instead of line graph |
|
| 46 | + |
|
| 47 | +Please check out the [wikipedia page for the Sieve of Eratosthenes](https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes) |
|
| 48 | + |
|
| 49 | +Here is an animated image of this sieve in action (from wikipedia): |
|
| 50 | + |
|
| 51 | + |
|
| 52 | + |
|
| 53 | +## REFERENCE |
|
| 54 | + |
|
| 55 | +The following are reference screenshots of what your implementations |
|
| 56 | +should approximate: |
|
| 57 | + |
|
| 58 | +### PNC2 C IMPLEMENTATION |
|
| 59 | + |
|
| 60 | + |
|
| 61 | + |
|
| 62 | +## SUBMISSION |
|
| 63 | + |
|
| 64 | +To be successful in this project, the following criteria (or their |
|
| 65 | +equivalent) must be met: |
|
| 66 | + |
|
| 67 | + * Project must be submit on time, by the deadline. |
|
| 68 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 69 | + * Processing must be correct based on input given and output requested |
|
| 70 | + * Output, if applicable, must be correct based on values input |
|
| 71 | + * Code must be nicely and consistently indented and aligned |
|
| 72 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 73 | + * Code must be commented |
|
| 74 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 75 | + * Track/version the source code in your private semester repository |
|
| 76 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 77 | + |
|
| 78 | +## SUBMIT TOOL USAGE |
|
| 79 | + |
|
| 80 | +Let's say you have completed work on the project, and are ready to |
|
| 81 | +submit, you would do the following (once on LAB46, with all your data |
|
| 82 | +present): |
|
| 83 | + |
|
| 84 | +``` |
|
| 85 | +lab46:~/src/SEMESTER/DESIG/pnc2$ make submit |
|
| 86 | +``` |
|
| 87 | + |
|
| 88 | +You should get some sort of confirmation indicating successful submission |
|
| 89 | +if all went according to plan. If not, check for typos and or locational |
|
| 90 | +mismatches. |
|
| 91 | + |
|
| 92 | +### RUBRIC |
|
| 93 | + |
|
| 94 | +I'll be evaluating the project based on the following criteria: |
|
| 95 | + |
|
| 96 | +``` |
|
| 97 | +260:pnc2:final tally of results (260/260) |
|
| 98 | +*:pnc2:submitted working C and assembly implementations [26/26] |
|
| 99 | +*:pnc2:graph produced from timing data produced [26/26] |
|
| 100 | +*:pnc2:post screenshots to class DISCORD channel [26/26] |
|
| 101 | +*:pnc2:processing is correct, and to specifications [26/26] |
|
| 102 | +*:pnc2:working sieve of eratosthenes implementation [52/52] |
|
| 103 | +*:pnc2:working soe with sqrt implementation [52/52] |
|
| 104 | +*:pnc2:all variants and combinations thereof operational [26/26] |
|
| 105 | +*:pnc2:timing data is taken out to at least 5 decimal places [26/26] |
|
| 106 | +``` |
|
| 107 | + |
|
| 108 | +### ADDITIONALLY |
|
| 109 | + |
|
| 110 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 111 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 112 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 113 | + * 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 |
haas/fall2026/cprog/projects/cit0.md
| ... | ... | @@ -0,0 +1,194 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: C INTEGER TYPES (cit0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To begin our exploration of programming, starting with an investigation |
|
| 8 | +into the various integer data types available in C, along with their |
|
| 9 | +properties. |
|
| 10 | + |
|
| 11 | +## GRABIT |
|
| 12 | + |
|
| 13 | +To assist with consistency across all implementations, data files for use |
|
| 14 | +with this project are available on lab46 via the **grabit** tool. Be sure |
|
| 15 | +to obtain it and ensure your implementation properly works with the |
|
| 16 | +provided data. |
|
| 17 | + |
|
| 18 | +``` |
|
| 19 | +lab46:~/src/SEMESTER/cprog$ grabit cprog cit0 |
|
| 20 | +``` |
|
| 21 | + |
|
| 22 | +Please study any provided code or supporting documents, and look up, |
|
| 23 | +experiment, and ask questions on aspects that you do not understand. |
|
| 24 | + |
|
| 25 | +## SCOPE |
|
| 26 | + |
|
| 27 | +This project will be exploring the nature of some of the data types |
|
| 28 | +available to us in the C Programming Language. How much space is |
|
| 29 | +allocated to each type, and what are the ranges available for each type? |
|
| 30 | + |
|
| 31 | +A program is provided that will display (to STDOUT) the size (in bytes), |
|
| 32 | +the lower and upper bounds of each studied type, and some other related |
|
| 33 | +information. |
|
| 34 | + |
|
| 35 | +The data types covered for this project will include **signed** (can be |
|
| 36 | +positive/negative) and **unsigned** (absolute values, no sign) variations |
|
| 37 | +of: |
|
| 38 | + |
|
| 39 | + * `char` |
|
| 40 | + * `short int` |
|
| 41 | + * `int` |
|
| 42 | + * `long int` |
|
| 43 | + * `long long int` |
|
| 44 | + |
|
| 45 | +The **sizeof()** and **fprintf()** functions, as well as arithmetic and |
|
| 46 | +logical operators, will be utilized in performing much of the work. |
|
| 47 | + |
|
| 48 | +## TASK |
|
| 49 | + |
|
| 50 | +Your task is to first study and understand what the provided code is |
|
| 51 | +doing. It is expected you will ask questions on discord to gain |
|
| 52 | +clarification. |
|
| 53 | + |
|
| 54 | +There is extensive commenting in place in the source file for you to |
|
| 55 | +read, which will explain many of the details about each item of |
|
| 56 | +information being obtained. |
|
| 57 | + |
|
| 58 | +Once you have an understanding of what is going on, extend the code to |
|
| 59 | +support the other types (both signed and unsigned). In total, you should |
|
| 60 | +have TEN total sections. |
|
| 61 | + |
|
| 62 | +## HEXADECIMAL |
|
| 63 | + |
|
| 64 | +When dealing with things like addresses and raw data on the computer |
|
| 65 | +(a **binary** device), it is common practice to interact in some |
|
| 66 | +power-of-two base, with base 16 (hexadecimal) being the most common in |
|
| 67 | +use today. |
|
| 68 | + |
|
| 69 | +I would encourage you to memorize and become very familiar with |
|
| 70 | +navigating the following table: |
|
| 71 | + |
|
| 72 | +| base 2 | base 8 | base 10 (unsigned) | base 10 (signed) | base 16 | |
|
| 73 | +| ------ | ------ | ------------------ | ---------------- | ------- | |
|
| 74 | +| `0000` | `000` | `0` | `+0` | `0x0` | |
|
| 75 | +| `0001` | `001` | `1` | `+1` | `0x1` | |
|
| 76 | +| `0010` | `002` | `2` | `+2` | `0x2` | |
|
| 77 | +| `0011` | `003` | `3` | `+3` | `0x3` | |
|
| 78 | +| `0100` | `004` | `4` | `+4` | `0x4` | |
|
| 79 | +| `0101` | `005` | `5` | `+5` | `0x5` | |
|
| 80 | +| `0110` | `006` | `6` | `+6` | `0x6` | |
|
| 81 | +| `0111` | `007` | `7` | `+7` | `0x7` | |
|
| 82 | +| `1000` | `010` | `8` | `-8` | `0x8` | |
|
| 83 | +| `1001` | `011` | `9` | `-7` | `0x9` | |
|
| 84 | +| `1010` | `012` | `10` | `-6` | `0xA` | |
|
| 85 | +| `1011` | `013` | `11` | `-5` | `0xB` | |
|
| 86 | +| `1100` | `014` | `12` | `-4` | `0xC` | |
|
| 87 | +| `1101` | `015` | `13` | `-3` | `0xD` | |
|
| 88 | +| `1110` | `016` | `14` | `-2` | `0xE` | |
|
| 89 | +| `1111` | `017` | `15` | `-1` | `0xF` | |
|
| 90 | + |
|
| 91 | +It might be worthwhile to ask questions about the nature of the values on |
|
| 92 | +this table on the class discord, to gain a better understanding of why |
|
| 93 | +these values are here, how they were derived, and what value they bring |
|
| 94 | +to our interaction with computers. |
|
| 95 | + |
|
| 96 | +## COMPILING |
|
| 97 | + |
|
| 98 | +The compilation process for working with your source code is as follows: |
|
| 99 | + |
|
| 100 | +``` |
|
| 101 | +lab46:~/src/SEMESTER/cprog/cit0$ gcc -Wall --std=gnu18 -o cit0 cit0.c |
|
| 102 | +lab46:~/src/SEMESTER/cprog/cit0$ |
|
| 103 | +``` |
|
| 104 | + |
|
| 105 | +Assuming there are no syntax errors or warnings, and everything compiled |
|
| 106 | +correctly, you should just get your prompt back. In the event of |
|
| 107 | +problems, the compiler will be sure to tell you about them. |
|
| 108 | + |
|
| 109 | +Conceptually, the arrangement is as follows: |
|
| 110 | + |
|
| 111 | +``` |
|
| 112 | +gcc -Wall --std=gnu18 -o BINARYFILE SOURCEFILE |
|
| 113 | +``` |
|
| 114 | + |
|
| 115 | +The `BINARYFILE` comes **immediately after** the **-o**, **NOT** the |
|
| 116 | +`SOURCEFILE` (the source file must never **immediately** follow a |
|
| 117 | +**-o**). It can precede, and such is perfectly valid (especially if you |
|
| 118 | +feel that way more intuitive). |
|
| 119 | + |
|
| 120 | +The `-Wall` (treat all warnings as errors, increase general verbosity |
|
| 121 | +about warnings) and `--std=gnu18` (switch compiler to use a newer |
|
| 122 | +standard of the C language, with GNU extensions) are options given to the |
|
| 123 | +compiler. |
|
| 124 | + |
|
| 125 | +## EXECUTION |
|
| 126 | + |
|
| 127 | +To execute your binary, we need to specify a path to it, so we use |
|
| 128 | +**./**, which basically references the current directory: |
|
| 129 | + |
|
| 130 | +``` |
|
| 131 | +lab46:~/src/SEMESTER/cprog/cit0$ ./cit0 |
|
| 132 | +signed char |
|
| 133 | +========================================= |
|
| 134 | +total size in bytes: 1 |
|
| 135 | +total size in bits: 8 |
|
| 136 | +value contains: 17 |
|
| 137 | +value exists in memory at: 0x7ffc1a16d967 |
|
| 138 | +minimum value represented: -128 |
|
| 139 | +maximum value represented: 127 |
|
| 140 | +possible distinct values: 256 |
|
| 141 | +========================================= |
|
| 142 | +``` |
|
| 143 | + |
|
| 144 | +Your completed program will have far more output: additional sections |
|
| 145 | +each representing one of the integer type combinations (a total of 10). |
|
| 146 | + |
|
| 147 | +## SUBMISSION |
|
| 148 | + |
|
| 149 | +To successfully complete this project, the following criteria must be |
|
| 150 | +met: |
|
| 151 | + |
|
| 152 | + * Code must compile/execute cleanly (no notes, warnings, nor errors) |
|
| 153 | + * Code must be nicely and consistently indented |
|
| 154 | + * Code must be well commented |
|
| 155 | + * Do NOT double space your code. Group like statements together. |
|
| 156 | + * Track/version the source code in your private semester repository |
|
| 157 | + * Submit a copy of your source code to me using the **submit** tool |
|
| 158 | + |
|
| 159 | +To submit this program to me using the **submit** tool, run the following |
|
| 160 | +command at your LAB46 prompt: |
|
| 161 | + |
|
| 162 | +``` |
|
| 163 | +lab46:~/src/SEMESTER/cprog/cit0$ make submit |
|
| 164 | +``` |
|
| 165 | + |
|
| 166 | +You should get some sort of confirmation indicating successful submission |
|
| 167 | +if all went according to plan. If not, check for typos and or locational |
|
| 168 | +mismatches. |
|
| 169 | + |
|
| 170 | +What I'll be looking for: |
|
| 171 | + |
|
| 172 | +### RUBRIC |
|
| 173 | + |
|
| 174 | +I'll be evaluating the project based on the following criteria: |
|
| 175 | + |
|
| 176 | +``` |
|
| 177 | +104:cit0:final tally of results (104/104) |
|
| 178 | +*:cit0:grabit the code on lab46 by Sunday before deadline [13/13] |
|
| 179 | +*:cit0:code is pushed to private semester repository [13/13] |
|
| 180 | +*:cit0:proper output formatting per specifications [13/13] |
|
| 181 | +*:cit0:clean compile, no compiler messages [13/13] |
|
| 182 | +*:cit0:each integer type explored in full [26/26] |
|
| 183 | +*:cit0:program conforms to project specifications [26/26] |
|
| 184 | +``` |
|
| 185 | + |
|
| 186 | +NOTE: spirit of the project includes using hexadecimal values and bitwise |
|
| 187 | +logic operators to set the pertinent upper/lower bounds. |
|
| 188 | + |
|
| 189 | +Additionally: |
|
| 190 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 191 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 192 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 193 | + * 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 |
|
| 194 | + |
haas/fall2026/cprog/projects/cnv0.md
| ... | ... | @@ -0,0 +1,168 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: CALCULATING N-ARY VALUES (cnv0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To create a program that can calculate and determine the number of factor |
|
| 8 | +pairs of a given number, starting with values composed of exactly 2 sets |
|
| 9 | +of factor pairs. |
|
| 10 | + |
|
| 11 | +## GRABIT |
|
| 12 | + |
|
| 13 | +To assist with consistency across all implementations, data files for use |
|
| 14 | +with this project are available on lab46 via the **grabit** tool. Be sure |
|
| 15 | +to obtain it and ensure your implementation properly works with the |
|
| 16 | +provided data. |
|
| 17 | + |
|
| 18 | +``` |
|
| 19 | +lab46:~/src/SEMESTER/cprog$ grabit cprog PROJECT |
|
| 20 | +``` |
|
| 21 | + |
|
| 22 | +## PROGRAM |
|
| 23 | + |
|
| 24 | +It is your task to write a program that, upon accepting various pieces of |
|
| 25 | +input from the user, computes the number of factor pairs of a given |
|
| 26 | +number, displaying its eligibility as a secondary number. |
|
| 27 | + |
|
| 28 | +## SPECIFICATIONS |
|
| 29 | + |
|
| 30 | +Your program should: |
|
| 31 | + |
|
| 32 | + * have valid, descriptive variable names of length *no shorter than* 4 symbols |
|
| 33 | + * have consistent, well-defined indentation (no less than 4 spaces per level of indentation) |
|
| 34 | + * all code within the same scope aligned to its indentation level |
|
| 35 | + * have proximal comments explaining your rationale (the why and how), throughout your code |
|
| 36 | + * to STDERR, prompt for the number (range appropriate of an unsigned long int) |
|
| 37 | + * properly store this in a variable of type **unsigned long int** |
|
| 38 | + * immediately after the input, check to make sure the input number is a positive number greater than or equal to 2; if in violation, display an error (to STDERR) and exit with a non-zero value. |
|
| 39 | + * proceed to evaluate the input number, determining whether or not it is a secondary (nary(2)) number. |
|
| 40 | + * if it is, display to STDOUT that it is a secondary number (see execution section below for message) |
|
| 41 | + * if it is not, display to STDOUT that it is not a secondary number (again, see execution section below) |
|
| 42 | + * using a single return statement at the conclusion of the code, return a 0 indicating successful operation |
|
| 43 | + |
|
| 44 | +Some additional points of consideration: |
|
| 45 | + |
|
| 46 | + * Note that the driving variables in your loops need to be at least of type **short int**, otherwise you may get a warning when you compile it. |
|
| 47 | + |
|
| 48 | +## PROCESS |
|
| 49 | + |
|
| 50 | +In general, you will be looking to do something like the following: |
|
| 51 | + |
|
| 52 | +``` |
|
| 53 | +DISPLAY PROMPT |
|
| 54 | +READ NUMBER |
|
| 55 | + |
|
| 56 | +SHOULD NUMBER BE LOWER THAN TWO: |
|
| 57 | + DISPLAY AN ERROR |
|
| 58 | + EXIT WITH A NON-ZERO STATUS |
|
| 59 | + |
|
| 60 | +SO LONG AS FACTOR IS LESS THAN NUMBER: |
|
| 61 | + SHOULD THE FACTOR BE A LEGITIMATE FACTOR OF NUMBER: |
|
| 62 | + INCREMENT COUNT OF FACTOR PAIRS |
|
| 63 | + SHOULD THIS NUMBER HAVE A SQUARE FACTOR: |
|
| 64 | + INCREMENT COUNT OF FACTOR PAIRS |
|
| 65 | + |
|
| 66 | +SHOULD THE NUMBER OF FACTOR PAIRS MATCH WHAT WE ARE LOOKING FOR: |
|
| 67 | + DISPLAY THAT NUMBER BEING PROCESSED IS OF THE NEEDED TYPE |
|
| 68 | +OTHERWISE: |
|
| 69 | + DISPLAY THAT THE NUMBER BEING PROCESSED IS NOT THE NEEDED TYPE |
|
| 70 | +``` |
|
| 71 | + |
|
| 72 | +## REFERENCE |
|
| 73 | + |
|
| 74 | +Copied as part of the grabit, inside your **cnv0/** subdirectory, will |
|
| 75 | +be a copy of my implementation (in executable form, by the name |
|
| 76 | +**ref_cnv0**), which abides by the project specifications. Please compare |
|
| 77 | +its output against that of your implementation. You can invoke the |
|
| 78 | +reference implementation by running the following: |
|
| 79 | + |
|
| 80 | +``` |
|
| 81 | +yoursystem:~/src/SEMESTER/cprog/cnv0$ make check |
|
| 82 | +Enter a number: 6 |
|
| 83 | +6 is a secondary number |
|
| 84 | +yoursystem:~/src/SEMESTER/cprog/cnv0$ |
|
| 85 | +``` |
|
| 86 | + |
|
| 87 | +## VERIFICATION |
|
| 88 | + |
|
| 89 | +In addition, I have also placed a **cnv0verify** script in that same |
|
| 90 | +subdirectory, which will test your program against a range of values, to |
|
| 91 | +determine overall correctness. You can run the verify script using the |
|
| 92 | +Makefile, as follows: |
|
| 93 | + |
|
| 94 | +``` |
|
| 95 | +yoursystem:~/src/SEMESTER/cprog/cnv0$ make verify |
|
| 96 | +[ 1] you have: err, should be: err [ 2] you have: no, should be: no |
|
| 97 | +[ 3] you have: no, should be: no [ 4] you have: yes, should be: yes |
|
| 98 | +[ 5] you have: no, should be: no [ 6] you have: yes, should be: yes |
|
| 99 | +[ 7] you have: no, should be: no [ 8] you have: yes, should be: yes |
|
| 100 | +[ 9] you have: yes, should be: yes [ 10] you have: yes, should be: yes |
|
| 101 | +[ 11] you have: no, should be: no [ 12] you have: no, should be: no |
|
| 102 | +[ 13] you have: no, should be: no [ 14] you have: yes, should be: yes |
|
| 103 | +[ 15] you have: yes, should be: yes [ 16] you have: no, should be: no |
|
| 104 | +[ 17] you have: no, should be: no [ 18] you have: no, should be: no |
|
| 105 | +[ 19] you have: no, should be: no [ 20] you have: no, should be: no |
|
| 106 | +[ 21] you have: yes, should be: yes [ 22] you have: yes, should be: yes |
|
| 107 | +[ 23] you have: no, should be: no [ 24] you have: no, should be: no |
|
| 108 | +[ 25] you have: yes, should be: yes [ 26] you have: yes, should be: yes |
|
| 109 | +[ 27] you have: yes, should be: yes [ 28] you have: no, should be: no |
|
| 110 | +[ 29] you have: no, should be: no [ 30] you have: no, should be: no |
|
| 111 | +[ 31] you have: no, should be: no [ 32] you have: no, should be: no |
|
| 112 | +[ 33] you have: yes, should be: yes [ 34] you have: yes, should be: yes |
|
| 113 | +[ 35] you have: yes, should be: yes [ 36] you have: no, should be: no |
|
| 114 | +yoursystem:~/src/SEMESTER/cprog/cnv0$ |
|
| 115 | +``` |
|
| 116 | + |
|
| 117 | +## SUBMISSION |
|
| 118 | + |
|
| 119 | +To successfully complete this project, the following criteria must be |
|
| 120 | +met: |
|
| 121 | + |
|
| 122 | + * Code must compile cleanly (no notes, warnings, nor errors) |
|
| 123 | + * Output must be correct, and match the form given in the sample output above. |
|
| 124 | + * Code must be nicely and consistently indented |
|
| 125 | + * Code must be well commented |
|
| 126 | + * Do NOT double space your code. Group like statements together. |
|
| 127 | + * Output Formatting (including spacing) of program must conform to the provided output (see above). |
|
| 128 | + * Track/version the source code in your private semester repository |
|
| 129 | + * Submit a copy of your source code to me using the **submit** tool. |
|
| 130 | + |
|
| 131 | +### SUBMIT TOOL USAGE |
|
| 132 | + |
|
| 133 | +To submit this program to me using the **submit** tool, run the following |
|
| 134 | +command at your lab46 prompt: |
|
| 135 | + |
|
| 136 | +``` |
|
| 137 | +lab46:~/src/SEMESTER/cprog/cnv0$ make submit |
|
| 138 | +``` |
|
| 139 | + |
|
| 140 | +And make sure you get no error messages. |
|
| 141 | + |
|
| 142 | +You should get some sort of confirmation indicating successful submission |
|
| 143 | +if all went according to plan. If not, check for typos and or locational |
|
| 144 | +mismatches. |
|
| 145 | + |
|
| 146 | +### RUBRIC |
|
| 147 | + |
|
| 148 | +I'll be evaluating the project based on the following criteria: |
|
| 149 | + |
|
| 150 | +``` |
|
| 151 | +182:cnv0:final tally of results (182/182) |
|
| 152 | +*:cnv0:resources obtained via grabit by Sunday before deadline [13/13] |
|
| 153 | +*:cnv0:proper error checking and status reporting performed [26/26] |
|
| 154 | +*:cnv0:correct variable types and name lengths used [13/13] |
|
| 155 | +*:cnv0:proper output formatting per specifications [26/26] |
|
| 156 | +*:cnv0:proper selection logic applied to perform comparisions [26/26] |
|
| 157 | +*:cnv0:proper iteration logic applied to carry out process [26/26] |
|
| 158 | +*:cnv0:runtime verify tests of submission succeed [26/26] |
|
| 159 | +*:cnv0:no negative compiler messages for program [13/13] |
|
| 160 | +*:cnv0:code is pushed to private semester repository [13/13] |
|
| 161 | +``` |
|
| 162 | + |
|
| 163 | +Additionally: |
|
| 164 | + |
|
| 165 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 166 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 167 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 168 | + * 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 |
haas/fall2026/cprog/projects/cnv1.md
| ... | ... | @@ -0,0 +1,452 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: CALCULATING N-ARY VALUES (cnv1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To create a program that can calculate and determine the number of factor |
|
| 8 | +pairs (nary value) over a given range of numbers. |
|
| 9 | + |
|
| 10 | +## BACKGROUND |
|
| 11 | + |
|
| 12 | +In mathematics, you have likely encountered the notion of "prime" |
|
| 13 | +numbers, those values which are divisible only by 1 and the number |
|
| 14 | +itself. |
|
| 15 | + |
|
| 16 | +Expanding our view on the situation, when considering factors of a |
|
| 17 | +number, we have the presence of a "factor pair"; ie a pair of two values |
|
| 18 | +that are evenly divisible into that number. |
|
| 19 | + |
|
| 20 | +For 17, a prime number, we have just ONE factor pair: 1 and 17: |
|
| 21 | + |
|
| 22 | + * `17 % 1 == 0` |
|
| 23 | + * `17 % 17 == 0` |
|
| 24 | + |
|
| 25 | +All other values (2-16) when we divide them into 17 results in a non-zero |
|
| 26 | +value for the remainder. |
|
| 27 | + |
|
| 28 | +In this way, prime, or primary, numbers, have exactly ONE factor pair. To |
|
| 29 | +further simplify matters, we can call it an N-ary(1) or nary(1) value. |
|
| 30 | +Where the number indicates the number of factor pairs. |
|
| 31 | + |
|
| 32 | +A secondary, or nary(2) number, on the other hand, has exactly TWO sets |
|
| 33 | +of factor pairs. |
|
| 34 | + |
|
| 35 | +Take the number 6, for instance: |
|
| 36 | + |
|
| 37 | + * factor pair of 1 and 6 |
|
| 38 | + * factor pair of 2 and 3 |
|
| 39 | + |
|
| 40 | +Where 17 was a primary number, 6 is a secondary number. |
|
| 41 | + |
|
| 42 | +### DETERMINING FACTOR PAIRS |
|
| 43 | + |
|
| 44 | +We are going to be exploring a basic, brute force, method of determining |
|
| 45 | +factors for a number, and that is the "trial by division" method. |
|
| 46 | + |
|
| 47 | +Here, we successively divide a number by potential factors, to see if the |
|
| 48 | +factor evenly divides into the number. For convenience, we will assume |
|
| 49 | +the 1 and number factor pair, because EVERY number is evenly divisible by |
|
| 50 | +1 and itself. |
|
| 51 | + |
|
| 52 | +So, the number 5: |
|
| 53 | + |
|
| 54 | + * `5 % 2 == 1` |
|
| 55 | + * `5 % 3 == 2` |
|
| 56 | + * `5 % 4 == 1` |
|
| 57 | + |
|
| 58 | +No other evenly divisible factors were found in the range 2-(N-1), |
|
| 59 | +therefore we are only left with the factor pair of 1 and N, making 5 an |
|
| 60 | +nary(1) value. |
|
| 61 | + |
|
| 62 | +The number 14: |
|
| 63 | + |
|
| 64 | + * `14 % 2 == 0` another factor! |
|
| 65 | + * `14 % 3 == 2` |
|
| 66 | + * `14 % 4 == 2` |
|
| 67 | + * `14 % 5 == 4` |
|
| 68 | + * `14 % 6 == 2` |
|
| 69 | + * `14 % 7 == 0` another factor! |
|
| 70 | + * `14 % 8 == 6` |
|
| 71 | + * `14 % 9 == 5` |
|
| 72 | + * `14 % 10 == 4` |
|
| 73 | + * `14 % 11 == 3` |
|
| 74 | + * `14 % 12 == 2` |
|
| 75 | + * `14 % 13 == 1` |
|
| 76 | + |
|
| 77 | +Because factor pairs ALWAYS come in a set of 2, we have the factor pairs |
|
| 78 | +of 1 and 14, along with 2 and 7. |
|
| 79 | + |
|
| 80 | +How about 12: |
|
| 81 | + |
|
| 82 | + * `12 % 2 == 0` |
|
| 83 | + * `12 % 3 == 0` |
|
| 84 | + * `12 % 4 == 0` |
|
| 85 | + * `12 % 5 == 2` |
|
| 86 | + * `12 % 6 == 0` |
|
| 87 | + * `12 % 7 == 5` |
|
| 88 | + * `12 % 8 == 4` |
|
| 89 | + * `12 % 9 == 3` |
|
| 90 | + * `12 % 10 == 2` |
|
| 91 | + * `12 % 11 == 1` |
|
| 92 | + |
|
| 93 | +There are 4 additional factors discovered here, giving us a total of 6 |
|
| 94 | +factors, or three factor pairs: |
|
| 95 | + |
|
| 96 | + * 1, 12 |
|
| 97 | + * 2, 6 |
|
| 98 | + * 3, 4 |
|
| 99 | + |
|
| 100 | +Notice also how the factors are nested: 1 and 12 are the outermost, 2 and |
|
| 101 | +6 are encapsulated within that, and inside there, 3 and 4. |
|
| 102 | + |
|
| 103 | +Because there are 3 factor pairs, 12 would be considered an nary(3) value |
|
| 104 | +(or a tertiary number). |
|
| 105 | + |
|
| 106 | +### COMMANDLINE ARGUMENTS |
|
| 107 | + |
|
| 108 | +To facilitate our activities, we will be making use of command-line |
|
| 109 | +arguments in our programs. |
|
| 110 | + |
|
| 111 | +Command-line arguments are simply the tokens (space-separated pieces of |
|
| 112 | +information) we provide to the computer at the prompt: |
|
| 113 | + |
|
| 114 | +``` |
|
| 115 | +lab46:~/src/SEMESTER/cprog/project$ ./project token1 token2 ... tokenN |
|
| 116 | +``` |
|
| 117 | + |
|
| 118 | +The operating system packages up this information and provides it to our |
|
| 119 | +program, allowing us to access it. |
|
| 120 | + |
|
| 121 | +The first token ("./project") will be the invocation of our program, |
|
| 122 | +allowing our programs to know what they are called. |
|
| 123 | + |
|
| 124 | +The second token is the argument that immediately follows (in our case, |
|
| 125 | +"token1"); the third is "token2", and on and on until our very last |
|
| 126 | +provided argument ("tokenN" in our conceptual example). |
|
| 127 | + |
|
| 128 | +In addition to all the arguments packaged together in an array of |
|
| 129 | +strings, we are also provided with a total overall argument count, so we |
|
| 130 | +can know how many elements there are in this array of strings. |
|
| 131 | + |
|
| 132 | +### ARGUMENT NAMING CONVENTIONS |
|
| 133 | + |
|
| 134 | +Although you can name them anything, conventionally in many documents |
|
| 135 | +these have been named: |
|
| 136 | + |
|
| 137 | + * **argc** (or **ac**): the argument count, a signed integer (`int argc`) |
|
| 138 | + * **argv** (or **av**): the array of strings (or an array of an array of char), a double pointer (`char **argv`) |
|
| 139 | + |
|
| 140 | +### ACCEPTING ARGUMENTS IN YOUR PROGRAM |
|
| 141 | + |
|
| 142 | +To access this command-line information, we provide arguments to our |
|
| 143 | +main() function, as follows: |
|
| 144 | + |
|
| 145 | +``` |
|
| 146 | +int main (int argc, char **argv) |
|
| 147 | +{ |
|
| 148 | +``` |
|
| 149 | + |
|
| 150 | +We then have access to those populated variables (when we run a program, |
|
| 151 | +we are calling main(), so it should make sense that the arguments we |
|
| 152 | +provide to our program are passed as parameters to our main() function, |
|
| 153 | +the starting point of our program). |
|
| 154 | + |
|
| 155 | +### ACCESSING OUR ARGUMENTS |
|
| 156 | + |
|
| 157 | +The arguments are accessible via the argv array, in the order they were |
|
| 158 | +specified: |
|
| 159 | + |
|
| 160 | + * argv[0]: program invocation (path + program name) |
|
| 161 | + * argv[1]: first argument to the program (2nd argument to the command-line) |
|
| 162 | + * argv[2]: second argument to the program (3rd overall on the command-line) |
|
| 163 | + * ... |
|
| 164 | + * argv[N]: the last provided argument |
|
| 165 | + |
|
| 166 | +N in this case is equivalent to (**argc - 1**), as is commonly the case |
|
| 167 | +with array size and addressing. |
|
| 168 | + |
|
| 169 | +Additionally, let's not forget the **argc** variable, an integer, which |
|
| 170 | +contains a count of arguments (argc `==` argument count). If we provided |
|
| 171 | +argv[0] through argv[4], argc would contain a 5 (because array elements |
|
| 172 | +0-4 indicate 5 distinct array elements). |
|
| 173 | + |
|
| 174 | +### EXAMPLE |
|
| 175 | + |
|
| 176 | +For example, if we had the following program: |
|
| 177 | + |
|
| 178 | +``` |
|
| 179 | +lab46:~/src/SEMESTER/cprog/project$ ./project 128 1 2 2048 |
|
| 180 | +``` |
|
| 181 | + |
|
| 182 | +We'd have: |
|
| 183 | + |
|
| 184 | + * `argv[0]`: "./project" |
|
| 185 | + * `argv[1]`: "128" (note, NOT the scalar integer 128, but a string) |
|
| 186 | + * `argv[2]`: "1" |
|
| 187 | + * `argv[3]`: "2" |
|
| 188 | + * `argv[4]`: "2048" |
|
| 189 | + |
|
| 190 | +and let's not forget: |
|
| 191 | + |
|
| 192 | + * argc: 5 (there are 5 things, argv indexes 0, 1, 2, 3, and 4) |
|
| 193 | + |
|
| 194 | +### SIMPLE ARGUMENT CHECKS |
|
| 195 | + |
|
| 196 | +While there are a number of checks we should perform, one of the first |
|
| 197 | +should be a check to see if the minimal number of arguments has been |
|
| 198 | +provided: |
|
| 199 | + |
|
| 200 | +``` |
|
| 201 | + if (argc < 3) // if less than 3 arguments (program_name + argv[1] + argv[2] == 3) have been provided |
|
| 202 | + { |
|
| 203 | + fprintf(stderr, "%s: insufficient number of arguments!\n", argv[0]); |
|
| 204 | + exit(1); |
|
| 205 | + } |
|
| 206 | +``` |
|
| 207 | + |
|
| 208 | +Trying to access a non-existent argument could result in a segmentation |
|
| 209 | +fault. ALWAYS check your count to ensure the desired argument exists at |
|
| 210 | +the given position. |
|
| 211 | + |
|
| 212 | +### HEADER FILES |
|
| 213 | + |
|
| 214 | +We don't need any extra header files to use command-line arguments, but |
|
| 215 | +we will need an additional header file to use the **atoi(3)** function, |
|
| 216 | +which we'll use to quickly turn the command-line parameter into an |
|
| 217 | +integer, if such an operation is needed; and that header file is |
|
| 218 | +**stdlib.h**, so be sure to include it with the others: |
|
| 219 | + |
|
| 220 | +``` |
|
| 221 | +#include <stdio.h> |
|
| 222 | +#include <stdlib.h> |
|
| 223 | +``` |
|
| 224 | + |
|
| 225 | +In the above example, if argv[1] was "128" and we actually wanted that as |
|
| 226 | +an integer (versus the string it is initially available as), we utilize |
|
| 227 | +**atoi(3)** in the following manner: |
|
| 228 | + |
|
| 229 | +``` |
|
| 230 | + int value = 0; |
|
| 231 | + |
|
| 232 | + value = atoi (argv[1]); |
|
| 233 | +``` |
|
| 234 | + |
|
| 235 | +NOTE: you will want to do proper error checking and first ensure that |
|
| 236 | +argv[1] even exists (by checking **argc**). Failure to do so may result |
|
| 237 | +in a segmentation fault. |
|
| 238 | + |
|
| 239 | +## GRABIT |
|
| 240 | + |
|
| 241 | +There is a grabit for this project, which will provide you with some |
|
| 242 | +files pertinent for performing this project. |
|
| 243 | + |
|
| 244 | +Run '**grabit**' on lab46 in the appropriate manner to obtain the files, |
|
| 245 | +then move them to your development system used in this class. |
|
| 246 | + |
|
| 247 | +## COMPILING |
|
| 248 | + |
|
| 249 | +Since there is a provided Makefile in the project grabit, we can use that |
|
| 250 | +to compile, either regularly: |
|
| 251 | + |
|
| 252 | +``` |
|
| 253 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ make |
|
| 254 | +``` |
|
| 255 | + |
|
| 256 | +Or, with debugging support: |
|
| 257 | + |
|
| 258 | +``` |
|
| 259 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ make debug |
|
| 260 | +``` |
|
| 261 | + |
|
| 262 | +## PROGRAM |
|
| 263 | + |
|
| 264 | +It is your task to write a program that, upon accepting various pieces of |
|
| 265 | +input from the user, computes the number of factor pairs of a given |
|
| 266 | +number or range of numbers, displaying to STDOUT all the numbers in that |
|
| 267 | +range that qualify as that N-ary value. |
|
| 268 | + |
|
| 269 | +## SPECIFICATIONS |
|
| 270 | + |
|
| 271 | +Your program should: |
|
| 272 | + |
|
| 273 | + * have valid, descriptive variable names of length //no shorter than// 4 symbols |
|
| 274 | + * have consistent, well-defined indentation (no less than 4 spaces per level of indentation) |
|
| 275 | + * all code within the same scope aligned to its indentation level |
|
| 276 | + * have proximal comments explaining your rationale and what is going on, throughout your code |
|
| 277 | + * from the command-line, obtain the needed parameters for your program (require these arguments to be present, displaying errors to STDERR and exiting if they are not present): |
|
| 278 | + * argv[1]: N-ary value (how many factor pairs are we requiring; 1 for prime, 2 for secondary, 3 for tertiary, etc.); this should be stored and managed as an **unsigned char**. |
|
| 279 | + * argv[2]: lower-bound (where to start processing, inclusive of the lower bound value); this should be stored in an **unsigned short int** |
|
| 280 | + * argv[3]: upper-bound (where to stop processing, inclusive of the upper bound value); this should be shored in an **unsigned short int** |
|
| 281 | + * immediately after parameter processing, check to make sure the specified parameters are positive numbers. Any deviations should be displayed as error messages to STDERR: |
|
| 282 | + * N-ary value must be between 1 and 16 (inclusive of 1 and 16) |
|
| 283 | + * on error display "ERROR: invalid nary value (#)!" and terminate execution sending back a 1 (the # should be the actual number in deviation) |
|
| 284 | + * lower bound must be between 2 and 40000 (inclusive of 2 and 40000) |
|
| 285 | + * on error display "ERROR: invalid lower bound (#)!" and terminate execution sending back a 2 (the # should be the actual number in deviation) |
|
| 286 | + * upper bound must be between 2 and 65000 (inclusive of 2 and 65000) |
|
| 287 | + * on error display "ERROR: invalid upper bound (#)!" and terminate execution sending back a 3 (the # should be the actual number in deviation) |
|
| 288 | + * on situation of lower bound being greater than upper bound, display "ERROR: lower bound (#) is larger than upper bound (#)!", terminating execution and sending back a 4 (the # should be the actual number in deviation) |
|
| 289 | + * proceed to evaluate the appropriate number range, determining whether or not it is an N-ary number of runtime specification |
|
| 290 | + * if it is, display the value to STDOUT in space-separated form (see execution section below for format) |
|
| 291 | + * if it is not, do not display anything related to that value (again, see execution section below) |
|
| 292 | + * using a single return statement at the conclusion of the code, return a 0 indicating successful operation |
|
| 293 | + * for all error results, use **exit()** instead; there should only be exactly ONE **return()** statement per function |
|
| 294 | + |
|
| 295 | +Some additional points of consideration: |
|
| 296 | + * Note that the driving variables in your loops need to be at least of type **short int**, otherwise you may get a warning when you compile it. |
|
| 297 | + |
|
| 298 | +## EXECUTION |
|
| 299 | + |
|
| 300 | +### PRIMARY NUMBER OUTPUT |
|
| 301 | + |
|
| 302 | +``` |
|
| 303 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 1 8 24 |
|
| 304 | +11 13 17 19 23 |
|
| 305 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ |
|
| 306 | +``` |
|
| 307 | + |
|
| 308 | +### SECONDARY NUMBER OUTPUT |
|
| 309 | + |
|
| 310 | +``` |
|
| 311 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 2 3 12 |
|
| 312 | +4 6 8 9 10 |
|
| 313 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ |
|
| 314 | +``` |
|
| 315 | + |
|
| 316 | +### TERTIARY NUMBER OUTPUT |
|
| 317 | + |
|
| 318 | +``` |
|
| 319 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 3 11 37 |
|
| 320 | +12 16 18 20 28 32 |
|
| 321 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ |
|
| 322 | +``` |
|
| 323 | + |
|
| 324 | +The execution of the program is short and simple- obtain the input, do |
|
| 325 | +the processing, produce the output, and then terminate. |
|
| 326 | + |
|
| 327 | +## REFERENCE |
|
| 328 | + |
|
| 329 | +In the CPROG public directory, inside the **cnv1/** subdirectory, will |
|
| 330 | +be a copy of my implementation (in executable form, by the name |
|
| 331 | +**ref_cnv1**), which abides by the project specifications. Please compare |
|
| 332 | +its output against that of your implementation. You can run "make check" |
|
| 333 | +to have it run your program through a few variations: |
|
| 334 | + |
|
| 335 | +``` |
|
| 336 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ make check |
|
| 337 | +n-ary(1) from 2 to 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 |
|
| 338 | +n-ary(2) from 2 to 50: 4 6 8 9 10 14 15 21 22 25 26 27 33 34 35 38 39 46 49 |
|
| 339 | +n-ary(3) from 2 to 50: 12 16 18 20 28 32 44 45 50 |
|
| 340 | +n-ary(4) from 2 to 50: 24 30 40 42 |
|
| 341 | +n-ary(5) from 2 to 50: 36 48 |
|
| 342 | +``` |
|
| 343 | + |
|
| 344 | +## VERIFICATION |
|
| 345 | + |
|
| 346 | +In addition, I have also placed a **cnv1verify** script in that same |
|
| 347 | +subdirectory, which will test your program against a range of values, to |
|
| 348 | +determine overall correctness. You can run it by doing a "make verify": |
|
| 349 | + |
|
| 350 | +``` |
|
| 351 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ make verify |
|
| 352 | +ERROR CHECK |
|
| 353 | +================= |
|
| 354 | +invalid nary (0): ERROR: invalid nary value (0)! |
|
| 355 | + exit status: 1, should be: 1 |
|
| 356 | +- - - - - - - |
|
| 357 | +invalid nary (17): ERROR: invalid nary value (17)! |
|
| 358 | + exit status: 1, should be: 1 |
|
| 359 | +- - - - - - - |
|
| 360 | +invalid lower (1): ERROR: invalid lower bound (1)! |
|
| 361 | + exit status: 2, should be: 2 |
|
| 362 | +- - - - - - - |
|
| 363 | +invalid lower (43100): ERROR: invalid lower bound (43100)! |
|
| 364 | + exit status: 2, should be: 2 |
|
| 365 | +- - - - - - - |
|
| 366 | +invalid upper (0): ERROR: invalid upper bound (0)! |
|
| 367 | + exit status: 3, should be: 3 |
|
| 368 | +- - - - - - - |
|
| 369 | +invalid upper (65501): ERROR: invalid upper bound (65501)! |
|
| 370 | + exit status: 3, should be: 3 |
|
| 371 | +- - - - - - - |
|
| 372 | +lower (300) bigger than upper (65): ERROR: lower bound (300) is larger than upper bound (65)! |
|
| 373 | + exit status: 4, should be: 4 |
|
| 374 | +- - - - - - - |
|
| 375 | +Press ENTER to continue verification tests |
|
| 376 | +nary( 1) |
|
| 377 | +======== |
|
| 378 | + have: >23 29 31 < |
|
| 379 | + need: >23 29 31 < |
|
| 380 | + |
|
| 381 | +nary( 2) |
|
| 382 | +======== |
|
| 383 | + have: >21 22 25 26 27 33 34 35 < |
|
| 384 | + need: >21 22 25 26 27 33 34 35 < |
|
| 385 | + |
|
| 386 | +nary( 3) |
|
| 387 | +======== |
|
| 388 | + have: >20 28 32 < |
|
| 389 | + need: >20 28 32 < |
|
| 390 | + |
|
| 391 | +nary( 4) |
|
| 392 | +======== |
|
| 393 | + have: >24 30 < |
|
| 394 | + need: >24 30 < |
|
| 395 | + |
|
| 396 | +nary( 5) |
|
| 397 | +======== |
|
| 398 | + have: >36 < |
|
| 399 | + need: >36 < |
|
| 400 | + |
|
| 401 | +yoursystem:~/src/SEMESTER/cprog/cnv1$ |
|
| 402 | +``` |
|
| 403 | + |
|
| 404 | +## SUBMISSION |
|
| 405 | + |
|
| 406 | +To successfully complete this project, the following criteria must be |
|
| 407 | +met: |
|
| 408 | + |
|
| 409 | + * Code must compile cleanly (no notes, warnings, nor errors) |
|
| 410 | + * Output must be correct, and match the form given in the sample output above. |
|
| 411 | + * Code must be nicely and consistently indented, to show scope and maximize readability |
|
| 412 | + * Code must be well commented (why and how comments) |
|
| 413 | + * Do NOT double space your code. Group like statements together. |
|
| 414 | + * Output Formatting (including spacing) of program must conform to the provided output (see above). |
|
| 415 | + * Track/version the source code in your private semester repository |
|
| 416 | + * Submit a copy of your source code to me using the **submit** tool. |
|
| 417 | + |
|
| 418 | +### SUBMIT TOOL USAGE |
|
| 419 | + |
|
| 420 | +To submit this program to me using the **submit** tool, run the following |
|
| 421 | +command at your lab46 prompt: |
|
| 422 | + |
|
| 423 | +``` |
|
| 424 | +lab46:~/src/SEMESTER/cprog/cnv1$ make submit |
|
| 425 | +``` |
|
| 426 | + |
|
| 427 | +And make sure you get no error messages. |
|
| 428 | + |
|
| 429 | +You should get some sort of confirmation indicating successful submission |
|
| 430 | +if all went according to plan. If not, check for typos and or locational |
|
| 431 | +mismatches. |
|
| 432 | + |
|
| 433 | +### RUBRIC |
|
| 434 | + |
|
| 435 | +What I'll be looking for: |
|
| 436 | + |
|
| 437 | +``` |
|
| 438 | +208:cnv1:final tally of results (208/208) |
|
| 439 | +*:cnv1:resources obtained via grabit by Sunday before deadline [24/24] |
|
| 440 | +*:cnv1:proper error checking and status reporting performed [36/36] |
|
| 441 | +*:cnv1:correct variable types and name lengths used [36/36] |
|
| 442 | +*:cnv1:proper output formatting per specifications [36/36] |
|
| 443 | +*:cnv1:runtime tests of submitted program succeed [36/36] |
|
| 444 | +*:cnv1:no negative compiler messages for program [20/20] |
|
| 445 | +*:cnv1:code is pushed to lab46 repository [20/20] |
|
| 446 | +``` |
|
| 447 | + |
|
| 448 | +Additionally: |
|
| 449 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 450 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 451 | + * Solutions not utilizing consistent, sensible indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 452 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/cprog/projects/dap0.md
| ... | ... | @@ -0,0 +1,227 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: DRAW A PICTURE (dap0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To adapt and experiment with a program that generates an image, before |
|
| 8 | +having extensive knowledge of the subject matter. |
|
| 9 | + |
|
| 10 | +Also to start some time-sensitive activities to ensure ground is broken |
|
| 11 | +on the project before the day it is due (see submission rubric below) |
|
| 12 | + |
|
| 13 | +## BACKGROUND |
|
| 14 | + |
|
| 15 | +For this project, you will be using a graphics design library to render |
|
| 16 | +the indicated image. |
|
| 17 | + |
|
| 18 | +## GRABIT |
|
| 19 | + |
|
| 20 | +I have prepared a `grabit` for resources related to this project. To |
|
| 21 | +obtain it: |
|
| 22 | + |
|
| 23 | +``` |
|
| 24 | +lab46:~/src/SEMESTER/DESIG$ grabit DESIG dap0 |
|
| 25 | +make: Entering directory '/var/public/SEMESTER/DESIG/dap0' |
|
| 26 | +'/var/public/SEMESTER/DESIG/dap0/Makefile' -> '/home/user/src/SEMESTER/DESIG/dap0/Makefile' |
|
| 27 | +'/var/public/SEMESTER/DESIG/dap0/dap0.c' -> '/home/user/src/SEMESTER/DESIG/dap0/dap0.c' |
|
| 28 | +make: Leaving directory '/var/public/SEMESTER/DESIG/dap0' |
|
| 29 | +lab46:~/src/SEMESTER/DESIG$ |
|
| 30 | +``` |
|
| 31 | + |
|
| 32 | +At which point you can change into the newly created and populated |
|
| 33 | +`dap0` directory. |
|
| 34 | + |
|
| 35 | +Be sure to **add**, **commit**, and **push** this to your lab46 clone of |
|
| 36 | +your repository. |
|
| 37 | + |
|
| 38 | +Then, on your pi/system, **pull** and **update** to get the files |
|
| 39 | +available there, or continue working on it on lab46. |
|
| 40 | + |
|
| 41 | +## TASK |
|
| 42 | + |
|
| 43 | +It is first your task to study the existing code, figuring out how to |
|
| 44 | +compile and run it, and to view the image it produces. |
|
| 45 | + |
|
| 46 | +Next, observing the composition of the image, study the code to try and |
|
| 47 | +ascertain how the various shapes are formed and positioned where they |
|
| 48 | +are, along with other elements like colors. |
|
| 49 | + |
|
| 50 | +You will want to experiment with the code, making small changes to see if |
|
| 51 | +you can predictably change the resulting image that it output. Once you |
|
| 52 | +get comfortable with it, and you can reliably make predictable changes, |
|
| 53 | +you can proceed to the submittable task: |
|
| 54 | + |
|
| 55 | +You will want to modify this program that generates an image according to |
|
| 56 | +the following specifications: |
|
| 57 | + |
|
| 58 | + * is a coherent image, consisting of a recognized theme |
|
| 59 | + * allocates and utilizes at least EIGHT (8) colors |
|
| 60 | + * image dimensions are no smaller than 1000 pixels on either axis |
|
| 61 | + * picture utilizes the bulk of the canvas |
|
| 62 | + * uses at least 3 instances of each of: |
|
| 63 | + * circle/ellipse |
|
| 64 | + * line |
|
| 65 | + * rectangle |
|
| 66 | + |
|
| 67 | +<!-- place a black, filled 2x2 rectangle at coordinates 0, 0 in the image --> |
|
| 68 | + |
|
| 69 | +The program will be an exercise in exploration: you will be given some |
|
| 70 | +example code that does something. You should poke at it to gain deeper |
|
| 71 | +understanding. Then you will, taking out the demo graphics, implement the |
|
| 72 | +needed steps to generate your intended picture. |
|
| 73 | + |
|
| 74 | +Your program should: |
|
| 75 | + |
|
| 76 | + * have valid, descriptive variable names of length *no shorter than* 3 symbols |
|
| 77 | + * have consistent, well-defined indentation (no less than 4 spaces per level of indentation) |
|
| 78 | + * all code within the same scope aligned to its indentation level |
|
| 79 | + * have proximal comments explaining your rationale and what is going on, throughout your code |
|
| 80 | + * perform the intended operation, outputting the correct/accurate information in indicated format |
|
| 81 | + |
|
| 82 | +<!-- mix a color, calling it "gray", using an RGB value of 0xA1, 0xA1, 0xA1 --> |
|
| 83 | + |
|
| 84 | +### LAB46 DEVELOPMENT |
|
| 85 | + |
|
| 86 | +If you desire, you can do this project entirely on the LAB46 SHELL |
|
| 87 | +SYSTEM, making use of your WEB DIRECTORY to view your image in a WEB |
|
| 88 | +BROWSER. |
|
| 89 | + |
|
| 90 | +### ON YOUR DEVELOPMENT SYSTEM |
|
| 91 | + |
|
| 92 | +You are also free to work on this project on your own Linux system, |
|
| 93 | +provided it has the necessary tools and libraries available to compile |
|
| 94 | +and run it. |
|
| 95 | + |
|
| 96 | +To utilize the needed functionality for this project, you will need to |
|
| 97 | +ensure you have the following packages installed: |
|
| 98 | + |
|
| 99 | + * **build-essential** |
|
| 100 | + * **libgd-dev** |
|
| 101 | + * **libgd-tools** |
|
| 102 | + * **libgd3** |
|
| 103 | + |
|
| 104 | +And any related packages that may be needed to support this endeavour. |
|
| 105 | + |
|
| 106 | +### COMPILING |
|
| 107 | + |
|
| 108 | +Since the grabit brought in a `Makefile`, if your code needs compiling |
|
| 109 | +you can compile your code simply by typing: **make** |
|
| 110 | + |
|
| 111 | +For this project, you can then run the program with: **make run** |
|
| 112 | + |
|
| 113 | +If on the LAB46 SHELL SYSTEM, you can get the image copied into your web |
|
| 114 | +space (under the **dap0/** subdirectory) by running: **make install** |
|
| 115 | + |
|
| 116 | +When done and ready to submit, only on the LAB46 SHELL SYSTEM: **make |
|
| 117 | +submit** |
|
| 118 | + |
|
| 119 | +## STRATEGY |
|
| 120 | + |
|
| 121 | +As with any process you are looking to describe or automate (in this |
|
| 122 | +case, both), if YOU do not personally understand or appreciate the steps |
|
| 123 | +involved, you are going to have a hard time communicating a proficient |
|
| 124 | +list of instructions to the computer to carry out. |
|
| 125 | + |
|
| 126 | +So, the FIRST order of business would be to, BY HAND, ON A SHEET OF GRAPH |
|
| 127 | +PAPER (consider this your PROTOTYPE): |
|
| 128 | + |
|
| 129 | + * START EARLY: Don't WASTE the abundance of time made available to you. Waiting until the last minute will only preserve frustration and confusion |
|
| 130 | + * decide what sort of picture you would like to "render" |
|
| 131 | + * practice plotting the elements out, figuring out how to best represent and fill the graph paper |
|
| 132 | + * determine what a good ratio of blocks to screen size would be (holding a 11"x8.5" sheet of graph paper in landscape orientation would be a good fit for the resolution of 1280x1024, for example. |
|
| 133 | + * mark up your appropriately sized and filled out prototype with the different colors the project calls for |
|
| 134 | + * ONCE you have worked out your scheme by hand, you can THEN proceed to start playing with the provided code |
|
| 135 | + * determine what shapes are being rendered (view it in a web browser or image viewer) |
|
| 136 | + * make changes to the shapes. Experiment and develop an understanding of the coordinate system and how you can predictably impact the shape as it is rendered in the image |
|
| 137 | + * once you understand how to manipulate the shapes, remove the demo shapes/comments and start laying down your own |
|
| 138 | + * the provided code infrastructure may not be adequate for the demands of the project, and will need to be **expanded** in some areas |
|
| 139 | + * see if you understand the patterns of the existing infrastructure, and explore attempts to expand it to support your project aims |
|
| 140 | + * ASK QUESTIONS so as to maintain an understanding of what is going on |
|
| 141 | + |
|
| 142 | +## VIEWING THE PICTURE |
|
| 143 | + |
|
| 144 | +Depending on your computing setup, choose the most practical means of |
|
| 145 | +viewing your program's image output: |
|
| 146 | + |
|
| 147 | +### VIEWING VIA THE WEB ON LAB46 |
|
| 148 | + |
|
| 149 | +If you have successfully built and run the code on LAB46, running the |
|
| 150 | +`install` line as documented above, you can view your handiwork through a |
|
| 151 | +web browser, by pointing it at the image in your LAB46 WEB SPACE: |
|
| 152 | + |
|
| 153 | + * `https://lab46.g7n.org/~user/dap0/dap0.png` |
|
| 154 | + |
|
| 155 | +Do NOTE that for the image to be properly updated after any code change, |
|
| 156 | +you will need to re-**compile**, re-**run**, and re-**install** as you |
|
| 157 | +did above. Neglecting to redo the steps will result in what appears to be |
|
| 158 | +a stale image that doesn't change or update. |
|
| 159 | + |
|
| 160 | +NOTE: sometimes the web browser caches previous results, you may have to |
|
| 161 | +refresh a few times on revisions to get changes to manifest. |
|
| 162 | + |
|
| 163 | +### VIEWING VIA YOUR DEVELOPMENT SYSTEM |
|
| 164 | + |
|
| 165 | +Open a file browser, web browser, or image viewer and navigate to/open up |
|
| 166 | +your **dap0.png** image in your **~/src/SEMESTER/desig/dap0/** directory. |
|
| 167 | + |
|
| 168 | +Rinse and repeat as you go through revisions. |
|
| 169 | + |
|
| 170 | +## PREVIOUS SEMESTER ENTRIES |
|
| 171 | + |
|
| 172 | +A selection of completed entries from prior semesters: |
|
| 173 | + |
|
| 174 | + * [previous dap0 entries (gallery)](https://lab46.g7n.org/~wedge/dap0/) |
|
| 175 | + |
|
| 176 | +## CURRENT SEMESTER ENTRIES |
|
| 177 | + |
|
| 178 | +Direct links to the default images of all doing dap0 this semester: |
|
| 179 | + |
|
| 180 | + * [dcastil2](https://lab46.g7n.org/~dcastil2/dap0/dap0.png) |
|
| 181 | + * [eraffer2](https://lab46.g7n.org/~eraffer2/dap0/dap0.png) |
|
| 182 | + * [erebus](https://lab46.g7n.org/~erebus/dap0/dap0.png) |
|
| 183 | + * [lbailey6](https://lab46.g7n.org/~lbailey6/dap0/dap0.png) |
|
| 184 | + * [ngugliel](https://lab46.g7n.org/~ngugliel/dap0/dap0.png) |
|
| 185 | + * [pw005820](https://lab46.g7n.org/~pw005820/dap0/dap0.png) |
|
| 186 | + * [rsmith18](https://lab46.g7n.org/~rsmith18/dap0/dap0.png) |
|
| 187 | + |
|
| 188 | +## SUBMISSION |
|
| 189 | + |
|
| 190 | +To successfully complete this project, the following criteria must be |
|
| 191 | +met: |
|
| 192 | + |
|
| 193 | + * Code must compile/execute cleanly (no notes, warnings, nor errors) |
|
| 194 | + * Code must be nicely and consistently indented |
|
| 195 | + * Code must be well commented |
|
| 196 | + * Do NOT double space your code. Group like statements together. |
|
| 197 | + * Track/version the source code in your private semester repository |
|
| 198 | + * Submit a copy of your source code to me using the **submit** tool |
|
| 199 | + |
|
| 200 | +To submit this program to me using the **submit** tool, run the following |
|
| 201 | +command at your LAB46 prompt: |
|
| 202 | + |
|
| 203 | +``` |
|
| 204 | +lab46:~/src/SEMESTER/DESIG/dap0$ make submit |
|
| 205 | +``` |
|
| 206 | + |
|
| 207 | +You should get some sort of confirmation indicating successful submission |
|
| 208 | +if all went according to plan. If not, check for typos and or locational |
|
| 209 | +mismatches. |
|
| 210 | + |
|
| 211 | +What I'll be looking for: |
|
| 212 | + |
|
| 213 | +``` |
|
| 214 | +78:dap0:final tally of results (78/78) |
|
| 215 | +*:dap0:post image created to #desig discord channel [13/13] |
|
| 216 | +*:dap0:grabit the code on lab46 by Sunday before deadline [13/13] |
|
| 217 | +*:dap0:code is pushed to private semester repository [13/13] |
|
| 218 | +*:dap0:no negative compiler/interpreter messages for program [13/13] |
|
| 219 | +*:dap0:proper output formatting per specifications [26/26] |
|
| 220 | +``` |
|
| 221 | + |
|
| 222 | +Additionally: |
|
| 223 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 224 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 225 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 226 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
|
| 227 | + |
haas/fall2026/cprog/projects/dow0.md
| ... | ... | @@ -0,0 +1,365 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: DAY OF WEEK (dow0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To begin our exploration of decision-making and more detailed |
|
| 8 | +process-following in C, implementing a program that uses a mental math |
|
| 9 | +technique to determine the day of the week that January 1st falls on for |
|
| 10 | +any year in the 21st century. |
|
| 11 | + |
|
| 12 | +## BACKGROUND |
|
| 13 | + |
|
| 14 | +Mental Math constitutes an intersection of mental tricks and math- |
|
| 15 | +instead of utilizing a purely math-only solution, textual manipulations |
|
| 16 | +or simplifications in the computational process may take place enabling |
|
| 17 | +an individual to, once having learned the process, solve such problems in |
|
| 18 | +their head, and typically without the use of a calculating device. |
|
| 19 | + |
|
| 20 | +The process in this case is one of simple (reduced) multiplication and |
|
| 21 | +mapping against a table. To wit: |
|
| 22 | + |
|
| 23 | +### DAY VALUES |
|
| 24 | + |
|
| 25 | +For this trick to work, we need to be familiar with the following table |
|
| 26 | +(a map of days to numeric values): |
|
| 27 | + |
|
| 28 | +| Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday | |
|
| 29 | +| ------ | ------- | --------- | -------- | ------ | -------- | ------ | |
|
| 30 | +| 1 | 2 | 3 | 4 | 5 | 6 | 7 or 0 | |
|
| 31 | + |
|
| 32 | +**NOTE:** Depending on how you implement your algorithm, you may find |
|
| 33 | +your approach prefers 7s OR 0s... you aren't necessarily going to be |
|
| 34 | +encountering them at random. Once you work through your approach, you |
|
| 35 | +will discover which one you end up with. |
|
| 36 | + |
|
| 37 | +### CALCULATING DAY OF THE WEEK BASED ON YEAR |
|
| 38 | + |
|
| 39 | +Okay, time for the magic. |
|
| 40 | + |
|
| 41 | +Let us try it on January 1st, 2014. |
|
| 42 | + |
|
| 43 | +### STEP 1: OBTAIN LAST TWO DIGITS OF THE YEAR |
|
| 44 | + |
|
| 45 | +In our example, we're working with `2014`, the last two digits are |
|
| 46 | +therefore: `14` |
|
| 47 | + |
|
| 48 | +You should be able to come up with a means of extracting this information |
|
| 49 | +in your program. |
|
| 50 | + |
|
| 51 | +### STEP 2: COMPUTE 25% AND DROP THE DECIMAL |
|
| 52 | + |
|
| 53 | +Even this is something we can do in our heads. I can think of two |
|
| 54 | +approaches right off the bat: |
|
| 55 | + |
|
| 56 | +Approach 1: 10 + 10 + 5 |
|
| 57 | + |
|
| 58 | +10% percent of anything is merely moving the decimal over one place to |
|
| 59 | +the left. 10% of 54 is 5.4 |
|
| 60 | + |
|
| 61 | +For our 2014 example, 10% of 14 is therefore 1.4 |
|
| 62 | + |
|
| 63 | +So we need two 10 percents... 1.4 + 1.4 = 2.8 |
|
| 64 | + |
|
| 65 | +Finally, 5% is half of 10% (half of 1.4 is 0.7), so 1.4 + 1.4 + 0.7 = 3.5 |
|
| 66 | + |
|
| 67 | +But, since we do not care about the decimal, we drop it and are left with |
|
| 68 | +just 3. |
|
| 69 | + |
|
| 70 | +Approach 2: half of half |
|
| 71 | + |
|
| 72 | +25% is a convenient value for us with respect to 100, allowing this |
|
| 73 | +optimized approach to work. |
|
| 74 | + |
|
| 75 | + * Half of 100 is 50 (50%) |
|
| 76 | + * Half of 50 is 25 (25%) -- hence the "half of half" |
|
| 77 | + |
|
| 78 | +So, `14` cut in half is `7`. |
|
| 79 | + |
|
| 80 | +`7` cut in half is `3.5`. |
|
| 81 | + |
|
| 82 | +Once again, dropping the decimal yields `3`. |
|
| 83 | + |
|
| 84 | +### STEP 3: ADD 25% TO YEAR VALUE |
|
| 85 | + |
|
| 86 | +Once we have our 25% value, go and add it back to our two-digit year |
|
| 87 | +value: |
|
| 88 | + |
|
| 89 | +`14 + 3 = 17` |
|
| 90 | + |
|
| 91 | +### STEP 4: SUBTRACT THE LARGEST FITTING MULTIPLE OF 7 |
|
| 92 | + |
|
| 93 | +Some multiples of 7: |
|
| 94 | + |
|
| 95 | +| 0 | 7 | 14 | 21 | 28 | 35 | 42 | 49 | |
|
| 96 | + |
|
| 97 | +So, with a value of 17, what is the largest multiple of 7 that is still |
|
| 98 | +less than (or equal to) 17? |
|
| 99 | + |
|
| 100 | +Hopefully you identified the 14 as the likely candidate. |
|
| 101 | + |
|
| 102 | +`17 - 14 = 3` |
|
| 103 | + |
|
| 104 | +### STEP 5: LOOK UP DAY IN TABLE |
|
| 105 | + |
|
| 106 | +We ended up with a 3 as the result for January 1st, 2014. |
|
| 107 | + |
|
| 108 | +Go and reference the `3` from that table... what day do we get? Does it |
|
| 109 | +match the actual day of the week for January 1st, 2014? |
|
| 110 | + |
|
| 111 | +``` |
|
| 112 | +lab46:~$ cal 01 2014 |
|
| 113 | + January 2014 |
|
| 114 | +Su Mo Tu We Th Fr Sa |
|
| 115 | + 1 2 3 4 |
|
| 116 | + 5 6 7 8 9 10 11 |
|
| 117 | +12 13 14 15 16 17 18 |
|
| 118 | +19 20 21 22 23 24 25 |
|
| 119 | +26 27 28 29 30 31 |
|
| 120 | + |
|
| 121 | +lab46:~$ |
|
| 122 | +``` |
|
| 123 | + |
|
| 124 | +Pretty neat, eh? |
|
| 125 | + |
|
| 126 | +### EXCEPTION: LEAP YEARS |
|
| 127 | + |
|
| 128 | +In the event of a leap year, we simply subtract `1` from the 25% value, |
|
| 129 | +and continue on as usual. |
|
| 130 | + |
|
| 131 | +Makes sense, right? Leap years add a day, so something ends up being "off |
|
| 132 | +by one". |
|
| 133 | + |
|
| 134 | +## SELECTION |
|
| 135 | + |
|
| 136 | +The computer follows instructions, one step at a time, in a top-down |
|
| 137 | +manner (starting at the first instruction, proceeding to the next, then |
|
| 138 | +the next, then the next, etc.) until it arrives at the end of the |
|
| 139 | +provided instructions. |
|
| 140 | + |
|
| 141 | +One such instruction available to us is that of the selection statement, |
|
| 142 | +of which we will focus specifically on the general-purpose and broadly |
|
| 143 | +used **if()**. |
|
| 144 | + |
|
| 145 | +An **if()** statement can make a decision, assuming that either the |
|
| 146 | +result of a comparison of two values, or the provided value, results in a |
|
| 147 | +true or false result |
|
| 148 | + |
|
| 149 | +Should the condition presented be true, perform a specific subset of |
|
| 150 | +instructions. If false, skip the processing of those instructions. |
|
| 151 | + |
|
| 152 | +The general presentation of an **if()** statement in your code will look |
|
| 153 | +like: |
|
| 154 | + |
|
| 155 | +``` |
|
| 156 | + int x = 7; |
|
| 157 | + int y = 2; |
|
| 158 | + int z = 0; |
|
| 159 | + |
|
| 160 | + ... |
|
| 161 | + |
|
| 162 | + z = x % y; // take the remainder of x divided by y |
|
| 163 | + if (z == 0) |
|
| 164 | + { |
|
| 165 | + first thing to do; |
|
| 166 | + next thing to do; |
|
| 167 | + ... |
|
| 168 | + nth thing to do; |
|
| 169 | + } |
|
| 170 | +``` |
|
| 171 | + |
|
| 172 | +The **condition** present will typically be in terms of two values being |
|
| 173 | +compared in some way, using one of the following relational operators |
|
| 174 | +available to us in C: |
|
| 175 | + |
|
| 176 | + * `==` is equal to |
|
| 177 | + * `!=` is not equal to |
|
| 178 | + * `<` is less than |
|
| 179 | + * `>` is greater than |
|
| 180 | + * `<=` is less than or equal to |
|
| 181 | + * `>=` is greater than or equal to |
|
| 182 | + |
|
| 183 | +In the example above, we were comparing the relationship of the value |
|
| 184 | +currently contained within the **z** variable, and the constant **0**, |
|
| 185 | +with respect to being equal. If the two match, the result is true (and we |
|
| 186 | +run what is inside the if() block). If false, we skip the if() block. |
|
| 187 | + |
|
| 188 | +There are further variations of the **if()**, which have to do with |
|
| 189 | +capturing additional scenarios. |
|
| 190 | + |
|
| 191 | +The next one is the **else**, a companion to the **if()**. Where the |
|
| 192 | +**if()** processes a set of included instructions in the event some |
|
| 193 | +provided condition is true, the **else** contains a set of instructions |
|
| 194 | +to process in the event that condition is false. |
|
| 195 | + |
|
| 196 | +``` |
|
| 197 | + int x = 7; |
|
| 198 | + int y = 2; |
|
| 199 | + int z = 0; |
|
| 200 | + |
|
| 201 | + ... |
|
| 202 | + |
|
| 203 | + z = x % y; // take the remainder of x divided by y |
|
| 204 | + if (z == 0) |
|
| 205 | + { |
|
| 206 | + first thing to do; |
|
| 207 | + next thing to do; |
|
| 208 | + ... |
|
| 209 | + nth thing to do; |
|
| 210 | + } |
|
| 211 | + else |
|
| 212 | + { |
|
| 213 | + first thing when false; |
|
| 214 | + next thing; |
|
| 215 | + ... |
|
| 216 | + nth thing; |
|
| 217 | + } |
|
| 218 | +``` |
|
| 219 | + |
|
| 220 | +When doing selection, the minimum needed is the **if()** statement. Once |
|
| 221 | +you have an **if()** statement, you can optionally append up to ONE |
|
| 222 | +**else** clause (or you can have none: it all depends on the nature of |
|
| 223 | +the condition you are testing, and what you'd like to do as a result). |
|
| 224 | + |
|
| 225 | +You can have multiple **if()** statements, each checking their unique |
|
| 226 | +condition, and each of those **if()** statements potentially having an |
|
| 227 | +associated **else** clause. |
|
| 228 | + |
|
| 229 | +Should the process call for a finer level of evaluation (say, you want to |
|
| 230 | +do something unique when a given variable is 0, and something different |
|
| 231 | +if 1, yet different if 2, etc.), we also have the ability to encapsulate |
|
| 232 | +that into our **if()** block (assuming we wouldn't be better served just |
|
| 233 | +having individual **if()** statements), by the use of the **else if()**: |
|
| 234 | + |
|
| 235 | +``` |
|
| 236 | + int x = 17; |
|
| 237 | + int y = 5; |
|
| 238 | + int z = 0; |
|
| 239 | + |
|
| 240 | + ... |
|
| 241 | + |
|
| 242 | + z = x % y; // take the remainder of x divided by y |
|
| 243 | + if (z == 0) |
|
| 244 | + { |
|
| 245 | + first thing to do; |
|
| 246 | + next thing to do; |
|
| 247 | + ... |
|
| 248 | + nth thing to do; |
|
| 249 | + } |
|
| 250 | + else if (z <= 3) |
|
| 251 | + { |
|
| 252 | + first thing to do; |
|
| 253 | + next thing to do; |
|
| 254 | + ... |
|
| 255 | + nth thing to do; |
|
| 256 | + } |
|
| 257 | + else if (z > 3) |
|
| 258 | + { |
|
| 259 | + first thing to do; |
|
| 260 | + next thing to do; |
|
| 261 | + ... |
|
| 262 | + nth thing to do; |
|
| 263 | + } |
|
| 264 | + else |
|
| 265 | + { |
|
| 266 | + first thing when false; |
|
| 267 | + next thing; |
|
| 268 | + ... |
|
| 269 | + nth thing; |
|
| 270 | + } |
|
| 271 | +``` |
|
| 272 | + |
|
| 273 | +Note that whether or not we have an **else if()**, and whether or not we |
|
| 274 | +have an **else**, we MUST (and first) have an **if()**. |
|
| 275 | + |
|
| 276 | +If we have an **else**, it necessarily comes last (it has no |
|
| 277 | +**condition**, it is the catch-all, the clause to handle things in the |
|
| 278 | +event none of the previous conditioned clauses matched). |
|
| 279 | + |
|
| 280 | +## PROGRAM |
|
| 281 | + |
|
| 282 | +It is your task to write the program that will use the above method to |
|
| 283 | +determine the day of the week any given January 1st in the 21st century |
|
| 284 | +falls on. |
|
| 285 | + |
|
| 286 | +Your program should: |
|
| 287 | + * prompt the user for the four digit year (input) |
|
| 288 | + * perform the task (process) |
|
| 289 | + * display the final value (output) |
|
| 290 | + |
|
| 291 | +## VERIFICATION |
|
| 292 | + |
|
| 293 | +Included in the grabit is a **dow0verify** script that can run your |
|
| 294 | +program through the entire gamut of years in this century, displaying the |
|
| 295 | +accuracy of results. |
|
| 296 | + |
|
| 297 | +It would be worthwhile to use it to ensure your final result is |
|
| 298 | +functional. |
|
| 299 | + |
|
| 300 | +## GRABIT |
|
| 301 | + |
|
| 302 | +I have prepared a `grabit` for resources related to this project. To |
|
| 303 | +obtain it: |
|
| 304 | + |
|
| 305 | +``` |
|
| 306 | +lab46:~/src/SEMESTER/DESIG$ grabit DESIG dow0 |
|
| 307 | +``` |
|
| 308 | + |
|
| 309 | +At which point you can change into the newly created and populated |
|
| 310 | +`dow0` directory. |
|
| 311 | + |
|
| 312 | +Be sure, using **git**, to **add**, **commit**, and **push** this to your |
|
| 313 | +lab46 clone of your repository. |
|
| 314 | + |
|
| 315 | +Then, if working on your pi/system, **git pull** to get the files |
|
| 316 | +available there, or continue working on it on lab46. |
|
| 317 | + |
|
| 318 | +## SUBMISSION |
|
| 319 | + |
|
| 320 | +To successfully complete this project, the following criteria must be |
|
| 321 | +met: |
|
| 322 | + |
|
| 323 | + * Code must compile/execute cleanly (no notes, warnings, nor errors) |
|
| 324 | + * Code must be nicely and consistently indented |
|
| 325 | + * Code must be well commented |
|
| 326 | + * Do NOT double space your code. Group like statements together. |
|
| 327 | + * Track/version the source code in your private semester repository |
|
| 328 | + * Submit a copy of your source code to me using the **submit** tool |
|
| 329 | + |
|
| 330 | +To submit this program to me using the **submit** tool, run the following |
|
| 331 | +command at your LAB46 prompt: |
|
| 332 | + |
|
| 333 | +``` |
|
| 334 | +lab46:~/src/SEMESTER/cprog/dow0$ make submit |
|
| 335 | +``` |
|
| 336 | + |
|
| 337 | +You should get some sort of confirmation indicating successful submission |
|
| 338 | +if all went according to plan. If not, check for typos and or locational |
|
| 339 | +mismatches. |
|
| 340 | + |
|
| 341 | +What I'll be looking for: |
|
| 342 | + |
|
| 343 | +### RUBRIC |
|
| 344 | + |
|
| 345 | +I'll be evaluating the project based on the following criteria: |
|
| 346 | + |
|
| 347 | +``` |
|
| 348 | +156:dow0:final tally of results (156/156) |
|
| 349 | +*:dow0:grabit the code on lab46 by Sunday before deadline [26/26] |
|
| 350 | +*:dow0:code is pushed to private semester repository [13/13] |
|
| 351 | +*:dow0:clean compile, no compiler messages [26/26] |
|
| 352 | +*:dow0:program conforms to project specifications [52/52] |
|
| 353 | +*:dow0:project submitted with 'make submit' [13/13] |
|
| 354 | +*:dow0:program passes verification checks [26/26] |
|
| 355 | +``` |
|
| 356 | + |
|
| 357 | +NOTE: The spirit of program implementation includes your process |
|
| 358 | +using the mental math approach, not a more seemingly-straightforward |
|
| 359 | +computational approach, or one given to you out of context by AI. |
|
| 360 | + |
|
| 361 | +Additionally: |
|
| 362 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 363 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 364 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 365 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/cprog/projects/fwg0.md
| ... | ... | @@ -0,0 +1,186 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Obtain the latest stable release source code, or latest repository code, |
|
| 8 | +of the `Vircon32` Fantasy Console, along with its `DevTools`, and modify |
|
| 9 | +the provided code to display a sprite, move it around the screen, and |
|
| 10 | +detect screen bounds. |
|
| 11 | + |
|
| 12 | +## TASK |
|
| 13 | + |
|
| 14 | +Obtain and install on your development system the latest stable release, |
|
| 15 | +or latest version of the repository code, of the `Vircon32` Fantasy |
|
| 16 | +Console, along with its `DevTools` (C compiler). |
|
| 17 | + |
|
| 18 | +NOTE: Do not add the source code or binary code to `Vircon32` or |
|
| 19 | +`DevTools` to your repository! Process these outside of your repository. |
|
| 20 | +Once installed, your files specifically related to your modified code |
|
| 21 | +SHOULD be added to your repository. |
|
| 22 | + |
|
| 23 | +There is a `README` file in the base directory of the Vircon32 |
|
| 24 | +`ComputerSoftware` directory that includes build instructions. |
|
| 25 | + |
|
| 26 | +Verify that it works, by testing the grabit code in its initial state by |
|
| 27 | +ensuring the `DevTools` work when called (`compile`, `assemble`, and |
|
| 28 | +`packrom`), and of course running it in the `Vircon32` emulator. |
|
| 29 | + |
|
| 30 | +Then, modify the program according to the following criteria: |
|
| 31 | + |
|
| 32 | +## PROGRAM |
|
| 33 | + |
|
| 34 | +You are to write a Vircon32 C program that does the following: |
|
| 35 | + |
|
| 36 | + * displays some "sprite" of your choosing on the screen |
|
| 37 | + * moves based on the control of the first gamepad (left, right, up, down) |
|
| 38 | + * screen bounds detection and handling (barrier or wrap-around) |
|
| 39 | + |
|
| 40 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 41 | + |
|
| 42 | +## URLs |
|
| 43 | + |
|
| 44 | +The main Vircon32 site can be found [here](https://www.vircon32.com/), be |
|
| 45 | +sure to note the link to the Vircon32 API. |
|
| 46 | + |
|
| 47 | +The code can be found on the [Vircon32 ComputerSoftware GitHub |
|
| 48 | +repository](https://github.com/vircon32/ComputerSoftware/) |
|
| 49 | + |
|
| 50 | +I would recommend against checking out the tutorials: too many have |
|
| 51 | +gotten into trouble being influenced by the code, running into issues |
|
| 52 | +trying to conform to project specifications. |
|
| 53 | + |
|
| 54 | +## CARTRIDGE BUILD PROCESS |
|
| 55 | + |
|
| 56 | +All of these steps can be automated with the use of the provided |
|
| 57 | +`Makefile` simply by typing `make` at the prompt. |
|
| 58 | + |
|
| 59 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 60 | +file as appropriate. |
|
| 61 | + |
|
| 62 | +### COMPILE |
|
| 63 | + |
|
| 64 | +First step is to compile the C code, which can be done with the following |
|
| 65 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 66 | + |
|
| 67 | +``` |
|
| 68 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ compile fwg0.c -o fwg0.asm |
|
| 69 | +``` |
|
| 70 | + |
|
| 71 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 72 | +code, which will then need to be assembled to machine code: |
|
| 73 | + |
|
| 74 | +### ASSEMBLE |
|
| 75 | + |
|
| 76 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 77 | +`assemble` DevTool to assemble the assembly: |
|
| 78 | + |
|
| 79 | +``` |
|
| 80 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ assemble fwg0.asm -o fwg0.vbin |
|
| 81 | +``` |
|
| 82 | + |
|
| 83 | +### IMAGE CONVERSTION |
|
| 84 | + |
|
| 85 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 86 | +format via the `png2vircon` tool: |
|
| 87 | + |
|
| 88 | +``` |
|
| 89 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ png2vircon background.png -o background.vtex |
|
| 90 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ png2vircon sprites.png -o sprites.vtex |
|
| 91 | +``` |
|
| 92 | + |
|
| 93 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 94 | +reference these textures: |
|
| 95 | + |
|
| 96 | +``` |
|
| 97 | + <binary path="fwg0.vbin" /> |
|
| 98 | + <textures> |
|
| 99 | + <texture path="background.vtex" /> |
|
| 100 | + <texture path="sprites.vtex" /> |
|
| 101 | + </textures> |
|
| 102 | +``` |
|
| 103 | + |
|
| 104 | +### AUDIO CONVERSION |
|
| 105 | + |
|
| 106 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 107 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 108 | + |
|
| 109 | +``` |
|
| 110 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 111 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 112 | +``` |
|
| 113 | + |
|
| 114 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 115 | +reference these sounds: |
|
| 116 | + |
|
| 117 | +``` |
|
| 118 | + <sounds> |
|
| 119 | + <sound path="backgroundmusic.vsnd" /> |
|
| 120 | + <sound path="soundfx.vsnd" /> |
|
| 121 | + </sounds> |
|
| 122 | +``` |
|
| 123 | + |
|
| 124 | +### PACKING THE ROM |
|
| 125 | + |
|
| 126 | +Once all the components have been built, you can pack them together into |
|
| 127 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 128 | + |
|
| 129 | +``` |
|
| 130 | +yoursystem:~/src/SEMESTER/cprog/fwg0$ packrom fwg0.xml |
|
| 131 | +``` |
|
| 132 | + |
|
| 133 | +## SUBMISSION |
|
| 134 | + |
|
| 135 | +To be successful in this project, the following criteria (or their |
|
| 136 | +equivalent) must be met: |
|
| 137 | + |
|
| 138 | + * Project must be submit on time, by the deadline. |
|
| 139 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 140 | + * Executed programs must display in a manner similar to provided output |
|
| 141 | + * output formatted, where applicable, must match that of project requirements |
|
| 142 | + * Processing must be correct based on input given and output requested |
|
| 143 | + * Output, if applicable, must be correct based on values input |
|
| 144 | + * Code must be nicely and consistently indented |
|
| 145 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 146 | + * Code must be commented |
|
| 147 | + * Any "to be implemented" comments **MUST** be removed |
|
| 148 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 149 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 150 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 151 | + * Track/version the source code in your private semester repository |
|
| 152 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 153 | + |
|
| 154 | +### SUBMIT TOOL USAGE |
|
| 155 | + |
|
| 156 | +Let's say you have completed work on the project, and are ready to |
|
| 157 | +submit, you would do the following: |
|
| 158 | + |
|
| 159 | +``` |
|
| 160 | +lab46:~/src/SEMESTER/cprog/fwg0$ make submit |
|
| 161 | +``` |
|
| 162 | + |
|
| 163 | +You should get some sort of confirmation indicating successful submission |
|
| 164 | +if all went according to plan. If not, check for typos and or locational |
|
| 165 | +mismatches. |
|
| 166 | + |
|
| 167 | +### RUBRIC |
|
| 168 | + |
|
| 169 | +I'll be evaluating the project based on the following criteria: |
|
| 170 | + |
|
| 171 | +``` |
|
| 172 | +234:fwg0:final tally of results (234/234) |
|
| 173 | +*:fwg0:code modified to meet project specifications [52/52] |
|
| 174 | +*:fwg0:grabit of project data by Sunday prior to duedate [26/26] |
|
| 175 | +*:fwg0:screenshot or video posted to class DISCORD of game running [52/52] |
|
| 176 | +*:fwg0:source file, XML file, build script, and cartridge submit [52/52] |
|
| 177 | +*:fwg0:code compiles, cartridge builds with no warning or error [26/26] |
|
| 178 | +*:fwg0:committed project related changes to private semester repo [26/26] |
|
| 179 | +``` |
|
| 180 | + |
|
| 181 | +Additionally: |
|
| 182 | + |
|
| 183 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 184 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 185 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 186 | + * 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 |
haas/fall2026/cprog/projects/fwg1.md
| ... | ... | @@ -0,0 +1,159 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Using your Vircon32 build and installation from fwg0, implement your own |
|
| 8 | +pong-like game: at least one paddle, at least one ball. Ball rebounds off |
|
| 9 | +the walls, reflects off the paddle. Simple score if the ball makes it |
|
| 10 | +past the paddle. |
|
| 11 | + |
|
| 12 | +## PROGRAM |
|
| 13 | + |
|
| 14 | +You are to write a Vircon32 C pong game: display the usual assets, with |
|
| 15 | +the expected mechanics and interactions (paddle, ball, collision, score). |
|
| 16 | + |
|
| 17 | + * a paddle, guarding one of the walls |
|
| 18 | + * paddle moves based on control of the gamepad |
|
| 19 | + * ball moves independently around the screen, rebounding/reflecting |
|
| 20 | + * ball rebounds off non-paddle walls |
|
| 21 | + * ball reflects off paddle when a collision occurs |
|
| 22 | + * scoring based on ball making it past the paddle |
|
| 23 | + |
|
| 24 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 25 | + |
|
| 26 | +## CARTRIDGE BUILD PROCESS |
|
| 27 | + |
|
| 28 | +All of these steps can be automated with the use of the provided |
|
| 29 | +`Makefile` simply by typing `make` at the prompt. |
|
| 30 | + |
|
| 31 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 32 | +file as appropriate. |
|
| 33 | + |
|
| 34 | +### COMPILE |
|
| 35 | + |
|
| 36 | +First step is to compile the C code, which can be done with the following |
|
| 37 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 38 | + |
|
| 39 | +``` |
|
| 40 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ compile fwg1.c -o fwg1.asm |
|
| 41 | +``` |
|
| 42 | + |
|
| 43 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 44 | +code, which will then need to be assembled to machine code: |
|
| 45 | + |
|
| 46 | +### ASSEMBLE |
|
| 47 | + |
|
| 48 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 49 | +`assemble` DevTool to assemble the assembly: |
|
| 50 | + |
|
| 51 | +``` |
|
| 52 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ assemble fwg1.asm -o fwg1.vbin |
|
| 53 | +``` |
|
| 54 | + |
|
| 55 | +### IMAGE CONVERSTION |
|
| 56 | + |
|
| 57 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 58 | +format via the `png2vircon` tool: |
|
| 59 | + |
|
| 60 | +``` |
|
| 61 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ png2vircon background.png -o background.vtex |
|
| 62 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ png2vircon sprites.png -o sprites.vtex |
|
| 63 | +``` |
|
| 64 | + |
|
| 65 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 66 | +reference these textures: |
|
| 67 | + |
|
| 68 | +``` |
|
| 69 | + <binary path="fwg1.vbin" /> |
|
| 70 | + <textures> |
|
| 71 | + <texture path="background.vtex" /> |
|
| 72 | + <texture path="sprites.vtex" /> |
|
| 73 | + </textures> |
|
| 74 | +``` |
|
| 75 | + |
|
| 76 | +### AUDIO CONVERSION |
|
| 77 | + |
|
| 78 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 79 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 80 | + |
|
| 81 | +``` |
|
| 82 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 83 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 84 | +``` |
|
| 85 | + |
|
| 86 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 87 | +reference these sounds: |
|
| 88 | + |
|
| 89 | +``` |
|
| 90 | + <sounds> |
|
| 91 | + <sound path="backgroundmusic.vsnd" /> |
|
| 92 | + <sound path="soundfx.vsnd" /> |
|
| 93 | + </sounds> |
|
| 94 | +``` |
|
| 95 | + |
|
| 96 | +### PACKING THE ROM |
|
| 97 | + |
|
| 98 | +Once all the components have been built, you can pack them together into |
|
| 99 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 100 | + |
|
| 101 | +``` |
|
| 102 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ packrom fwg1.xml |
|
| 103 | +``` |
|
| 104 | + |
|
| 105 | +## SUBMISSION |
|
| 106 | + |
|
| 107 | +To be successful in this project, the following criteria (or their |
|
| 108 | +equivalent) must be met: |
|
| 109 | + |
|
| 110 | + * Project must be submit on time, by the deadline. |
|
| 111 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 112 | + * Executed programs must display in a manner similar to provided output |
|
| 113 | + * output formatted, where applicable, must match that of project requirements |
|
| 114 | + * Processing must be correct based on input given and output requested |
|
| 115 | + * Output, if applicable, must be correct based on values input |
|
| 116 | + * Code must be nicely and consistently indented |
|
| 117 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 118 | + * Code must be commented |
|
| 119 | + * Any "to be implemented" comments **MUST** be removed |
|
| 120 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 121 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 122 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 123 | + * Track/version the source code in your private semester repository |
|
| 124 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 125 | + |
|
| 126 | +### SUBMIT TOOL USAGE |
|
| 127 | + |
|
| 128 | +Let's say you have completed work on the project, and are ready to |
|
| 129 | +submit, you would do the following: |
|
| 130 | + |
|
| 131 | +``` |
|
| 132 | +lab46:~/src/SEMESTER/cprog/fwg1$ make submit |
|
| 133 | +``` |
|
| 134 | + |
|
| 135 | +You should get some sort of confirmation indicating successful submission |
|
| 136 | +if all went according to plan. If not, check for typos and or locational |
|
| 137 | +mismatches. |
|
| 138 | + |
|
| 139 | +### RUBRIC |
|
| 140 | + |
|
| 141 | +I'll be evaluating the project based on the following criteria: |
|
| 142 | + |
|
| 143 | +``` |
|
| 144 | +260:fwg1:final tally of results (260/260) |
|
| 145 | +*:fwg1:code modified to meet project specifications [52/52] |
|
| 146 | +*:fwg1:grabit of project data by Sunday prior to duedate [26/26] |
|
| 147 | +*:fwg1:screenshot or video posted to class DISCORD of game running [26/26] |
|
| 148 | +*:fwg1:working collision detection between paddle and ball [52/52] |
|
| 149 | +*:fwg1:source file, XML file, build script, and cartridge submit [26/26] |
|
| 150 | +*:fwg1:code compiles, cartridge builds with no warning or error [26/26] |
|
| 151 | +*:fwg1:committed project related changes to private semester repo [52/52] |
|
| 152 | +``` |
|
| 153 | + |
|
| 154 | +Additionally: |
|
| 155 | + |
|
| 156 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 157 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 158 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 159 | + * 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 |
haas/fall2026/cprog/projects/fwg2.md
| ... | ... | @@ -0,0 +1,168 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Using your Vircon32 build and installation from fwg0, and pong foundation |
|
| 8 | +from fwg1, implement your own breakout-like game: at least one paddle, at |
|
| 9 | +least one ball. Ball rebounds off the walls, reflects off the paddle. An |
|
| 10 | +array of bricks displayed on the screen, which vanish once colliding with |
|
| 11 | +the ball. Score based on bricks hit. |
|
| 12 | + |
|
| 13 | +## PROGRAM |
|
| 14 | + |
|
| 15 | +You are to write a Vircon32 C breakout game: display the usual assets, |
|
| 16 | +with the expected mechanics and interactions (paddle, ball, bricks, |
|
| 17 | +collision, score). |
|
| 18 | + |
|
| 19 | + * a paddle, guarding one of the walls |
|
| 20 | + * paddle moves based on control of the gamepad |
|
| 21 | + * ball moves independently around the screen, rebounding/reflecting |
|
| 22 | + * ball rebounds off non-paddle walls |
|
| 23 | + * ball reflects off brick when a ball-brick collision occurs |
|
| 24 | + * brick disappears upon collision with ball |
|
| 25 | + * ball reflects off paddle when a ball-paddle collision occurs |
|
| 26 | + * scoring based on brick collisions |
|
| 27 | + * use an array to manage the bricks |
|
| 28 | + * use a loop to transact the array |
|
| 29 | + |
|
| 30 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 31 | + |
|
| 32 | +## CARTRIDGE BUILD PROCESS |
|
| 33 | + |
|
| 34 | +All of these steps can be automated with the use of the provided |
|
| 35 | +`Makefile` simply by typing `make` at the prompt. |
|
| 36 | + |
|
| 37 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 38 | +file as appropriate. |
|
| 39 | + |
|
| 40 | +### COMPILE |
|
| 41 | + |
|
| 42 | +First step is to compile the C code, which can be done with the following |
|
| 43 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 44 | + |
|
| 45 | +``` |
|
| 46 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ compile fwg2.c -o fwg2.asm |
|
| 47 | +``` |
|
| 48 | + |
|
| 49 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 50 | +code, which will then need to be assembled to machine code: |
|
| 51 | + |
|
| 52 | +### ASSEMBLE |
|
| 53 | + |
|
| 54 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 55 | +`assemble` DevTool to assemble the assembly: |
|
| 56 | + |
|
| 57 | +``` |
|
| 58 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ assemble fwg2.asm -o fwg2.vbin |
|
| 59 | +``` |
|
| 60 | + |
|
| 61 | +### IMAGE CONVERSTION |
|
| 62 | + |
|
| 63 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 64 | +format via the `png2vircon` tool: |
|
| 65 | + |
|
| 66 | +``` |
|
| 67 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ png2vircon background.png -o background.vtex |
|
| 68 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ png2vircon sprites.png -o sprites.vtex |
|
| 69 | +``` |
|
| 70 | + |
|
| 71 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 72 | +reference these textures: |
|
| 73 | + |
|
| 74 | +``` |
|
| 75 | + <binary path="fwg2.vbin" /> |
|
| 76 | + <textures> |
|
| 77 | + <texture path="background.vtex" /> |
|
| 78 | + <texture path="sprites.vtex" /> |
|
| 79 | + </textures> |
|
| 80 | +``` |
|
| 81 | + |
|
| 82 | +### AUDIO CONVERSION |
|
| 83 | + |
|
| 84 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 85 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 86 | + |
|
| 87 | +``` |
|
| 88 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 89 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 90 | +``` |
|
| 91 | + |
|
| 92 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 93 | +reference these sounds: |
|
| 94 | + |
|
| 95 | +``` |
|
| 96 | + <sounds> |
|
| 97 | + <sound path="backgroundmusic.vsnd" /> |
|
| 98 | + <sound path="soundfx.vsnd" /> |
|
| 99 | + </sounds> |
|
| 100 | +``` |
|
| 101 | + |
|
| 102 | +### PACKING THE ROM |
|
| 103 | + |
|
| 104 | +Once all the components have been built, you can pack them together into |
|
| 105 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 106 | + |
|
| 107 | +``` |
|
| 108 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ packrom fwg2.xml |
|
| 109 | +``` |
|
| 110 | + |
|
| 111 | +## SUBMISSION |
|
| 112 | + |
|
| 113 | +To be successful in this project, the following criteria (or their |
|
| 114 | +equivalent) must be met: |
|
| 115 | + |
|
| 116 | + * Project must be submit on time, by the deadline. |
|
| 117 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 118 | + * Executed programs must display in a manner similar to provided output |
|
| 119 | + * output formatted, where applicable, must match that of project requirements |
|
| 120 | + * Processing must be correct based on input given and output requested |
|
| 121 | + * Output, if applicable, must be correct based on values input |
|
| 122 | + * Code must be nicely and consistently indented |
|
| 123 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 124 | + * Code must be commented |
|
| 125 | + * Any "to be implemented" comments **MUST** be removed |
|
| 126 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 127 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 128 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 129 | + * Track/version the source code in your private semester repository |
|
| 130 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 131 | + |
|
| 132 | +### SUBMIT TOOL USAGE |
|
| 133 | + |
|
| 134 | +Let's say you have completed work on the project, and are ready to |
|
| 135 | +submit, you would do the following: |
|
| 136 | + |
|
| 137 | +``` |
|
| 138 | +lab46:~/src/SEMESTER/cprog/fwg2$ make submit |
|
| 139 | +``` |
|
| 140 | + |
|
| 141 | +You should get some sort of confirmation indicating successful submission |
|
| 142 | +if all went according to plan. If not, check for typos and or locational |
|
| 143 | +mismatches. |
|
| 144 | + |
|
| 145 | +### RUBRIC |
|
| 146 | + |
|
| 147 | +I'll be evaluating the project based on the following criteria: |
|
| 148 | + |
|
| 149 | +``` |
|
| 150 | +286:fwg2:final tally of results (286/286) |
|
| 151 | +*:fwg2:code modified to meet project specifications [26/26] |
|
| 152 | +*:fwg2:grabit of project data by Sunday prior to duedate [26/26] |
|
| 153 | +*:fwg2:screenshot or video posted to class DISCORD of game running [26/26] |
|
| 154 | +*:fwg2:working collision detection between paddle and ball [26/26] |
|
| 155 | +*:fwg2:working collision between ball and individual bricks [26/26] |
|
| 156 | +*:fwg2:code makes use of an array to manage the bricks [26/26] |
|
| 157 | +*:fwg2:code uses a loop to transact the array [26/26] |
|
| 158 | +*:fwg2:source file, XML file, build script, and cartridge submit [26/26] |
|
| 159 | +*:fwg2:code compiles, cartridge builds with no warning or error [26/26] |
|
| 160 | +*:fwg2:committed project related changes to private semester repo [52/52] |
|
| 161 | +``` |
|
| 162 | + |
|
| 163 | +Additionally: |
|
| 164 | + |
|
| 165 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 166 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 167 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 168 | + * 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 |
haas/fall2026/cprog/projects/oop0.md
| ... | ... | @@ -0,0 +1,189 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: OBJECT-ORIENTED PROGRAMMING (oop0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Explore the basics of C++ programming, specifically the creation of |
|
| 8 | +classes and instantiation of objects, and the implementation of a simple |
|
| 9 | +program that has and uses a class. |
|
| 10 | + |
|
| 11 | +The idea is to demonstrate your skills gained throughout the semester, by |
|
| 12 | +harnessing new concepts and problem solving experiences to delve into |
|
| 13 | +this new area of the course: C++ and object-oriented programming. |
|
| 14 | + |
|
| 15 | +## C++ |
|
| 16 | + |
|
| 17 | +### BACKSTORY |
|
| 18 | + |
|
| 19 | +In the 1960s-1990s many computer programming languages were being created |
|
| 20 | +for different purposes, but most of them had flaws. Some languages were |
|
| 21 | +easy to understand, but lacked the depth to accomplish more difficult |
|
| 22 | +tasks. Others had this capability, but were large, abstract, and very |
|
| 23 | +difficult to learn, thus leading people to create more with the goal of |
|
| 24 | +having a language that was not too complex, but could effectively |
|
| 25 | +complete difficult tasks. This eventually led to a C language that was |
|
| 26 | +good for low level programming, and a SIMULA language that had a class |
|
| 27 | +system. C++ language was the creation of Bjarne Stroustrup that combined |
|
| 28 | +these two. |
|
| 29 | + |
|
| 30 | +The main difference between the two is that C is a procedural programming |
|
| 31 | +language, whereas C++ is a hybrid language that can perform both |
|
| 32 | +procedural and object-oriented programming. C supports built in data |
|
| 33 | +types, whereas C++ can support both built-in and user defined data types. |
|
| 34 | +C has 32 keywords, whereas C++ has 63 keywords, and C++ supports far more |
|
| 35 | +things in general than C. From a security standpoint, C does not support |
|
| 36 | +encapsulation so data can be manipulated by outside code meanwhile C++ |
|
| 37 | +supports encapsulation so the data is hidden. |
|
| 38 | + |
|
| 39 | +C++ is still updated today because it is still so widely used today, due |
|
| 40 | +to its speed, programming capability, and its continued popularity in |
|
| 41 | +being used (even if a superior language did come out computer scientists |
|
| 42 | +would still have to learn that new language, and languages already |
|
| 43 | +written in C++ would still be written in C++). |
|
| 44 | + |
|
| 45 | +C++ is most notably used in the creation of high performance programs, |
|
| 46 | +such as video games, operating systems, and the Google Chrome and Firefox |
|
| 47 | +web browsers. |
|
| 48 | + |
|
| 49 | +C++ is a play on the ++ increment operator in C language. |
|
| 50 | + |
|
| 51 | +C++ was originally called 'The New C'. |
|
| 52 | + |
|
| 53 | +C++ has influenced other programming languages such as C# and Java. |
|
| 54 | + |
|
| 55 | +### OOP |
|
| 56 | + |
|
| 57 | +Object Oriented Programming refers to a type of programming that uses |
|
| 58 | +objects that contain both data and functions. This is opposed to |
|
| 59 | +procedural programming, which is about writing procedures or functions |
|
| 60 | +that perform operations. OOP has several advantages over Procedural |
|
| 61 | +Programming which include: |
|
| 62 | + |
|
| 63 | + * OOP provides a management structure for programs. |
|
| 64 | + * OOP helps make code easier to maintain, modify and debug. |
|
| 65 | + * OOP makes it possible to create reusable applications with less code and a shorter development time. |
|
| 66 | + |
|
| 67 | +## CLASSES |
|
| 68 | + |
|
| 69 | +Classes are effectively user defined data types. They make it easier |
|
| 70 | +to work with data by providing users with the ability to create |
|
| 71 | +constructors, destructors, member data, member functions, and more. |
|
| 72 | + |
|
| 73 | +In C++, you can define data inside of classes for the sake of using them |
|
| 74 | +with member functions. Access specifiers can be used to determine where |
|
| 75 | +these variables can be called from, and which functions can call them. |
|
| 76 | +(This is further described down below) |
|
| 77 | + |
|
| 78 | +Methods are functions that belong to a class. The two ways to define a |
|
| 79 | +function that belongs to a class are inside the class definition and |
|
| 80 | +outside the class definition. In order to define a method outside the |
|
| 81 | +class definition, you must first declare it inside the class. You can |
|
| 82 | +then define your function outside of the class by specifying the name of |
|
| 83 | +the class and following it with the "::" operator. These functions are |
|
| 84 | +meant to be used alongside member data. |
|
| 85 | + |
|
| 86 | +Constructors are functions that are called when an object is created. |
|
| 87 | +They can be used with or without parameters, similarly to any other type |
|
| 88 | +of function. They do not return any values. |
|
| 89 | + |
|
| 90 | +Destructors are special functions that are called in any of the below |
|
| 91 | +conditions: |
|
| 92 | + |
|
| 93 | + * the function ends |
|
| 94 | + * the program ends |
|
| 95 | + * a block containing local variables ends |
|
| 96 | + * a delete operator is called |
|
| 97 | + |
|
| 98 | +They are meant to be used when a pointer is used in a class, or when |
|
| 99 | +memory has been dynamically allocated, in order to prevent memory |
|
| 100 | +leakage. |
|
| 101 | + |
|
| 102 | +C++ classes are by default value types. Value types typically deal with |
|
| 103 | +memory or layout control, whereas, reference types are related to base |
|
| 104 | +classes and virtual functions for polymorphic purposes. A difference |
|
| 105 | +between the two types, is that value types are copyable, meaning, there |
|
| 106 | +is a copy constructor and copy assignment operator. Reference types on |
|
| 107 | +the other hand, make the class non-copyable, using a virtual destructor. |
|
| 108 | +Changing the class type is something that is done by the user/programmer, |
|
| 109 | +and is done by disabling the copy constructor and copy assignment |
|
| 110 | +operator. In short value types are about creating two values that can |
|
| 111 | +each be modified, whereas, reference types are more about identity. |
|
| 112 | + |
|
| 113 | +### ACCESS CONTROL |
|
| 114 | + |
|
| 115 | +Public members can be accessed in any part of the program. |
|
| 116 | + |
|
| 117 | +Private members can only be accessed by members of the same class. |
|
| 118 | + |
|
| 119 | +Protected members can be accessed by members of the same class, friend |
|
| 120 | +classes, and derived classes. |
|
| 121 | + |
|
| 122 | +Struct members are public by default. |
|
| 123 | + |
|
| 124 | +Class members are private by default. |
|
| 125 | + |
|
| 126 | +## INHERITANCE |
|
| 127 | + |
|
| 128 | +Single inheritance is when one class inherits directly from one other |
|
| 129 | +class. This is typical for most classes. Public inheritance does not |
|
| 130 | +change in subclasses from the parent class. Protected inheritance refers |
|
| 131 | +to when anything higher than protected will be protected. Both public and |
|
| 132 | +protected properties will be protected in a subclass. Private inheritance |
|
| 133 | +takes this a step further as all three inheritance types will be made |
|
| 134 | +private in a subclass. |
|
| 135 | + |
|
| 136 | +### OBJECTS |
|
| 137 | + |
|
| 138 | +Instances of a class. Creating an object of a class works almost exactly |
|
| 139 | +like initializing any fundamental type; simply specify the the type name, |
|
| 140 | +followed by your variable's name. Objects are introduced by declarations. |
|
| 141 | + |
|
| 142 | +## PROGRAM |
|
| 143 | + |
|
| 144 | +Write a program that: |
|
| 145 | + |
|
| 146 | + * creates one or more classes. |
|
| 147 | + * That contains, in addition to at least 2 constructors (parameterless, and a parametered), various supporting member functions |
|
| 148 | + * utilizes access control, and makes use of private member data |
|
| 149 | + |
|
| 150 | +Have a main() function that instantiates an instance of your chosen |
|
| 151 | +class, and runs that instantiated object through a range of tests |
|
| 152 | +demonstrating the class works as intended (likely also prompting the user |
|
| 153 | +to input values to configure the attributes of the object). |
|
| 154 | + |
|
| 155 | +Compile the program with the `g++` compiler (it uses many of the same |
|
| 156 | +basic arguments as `gcc`) |
|
| 157 | + |
|
| 158 | +## REFERENCES |
|
| 159 | + |
|
| 160 | + * https://www.learncpp.com/cpp-tutorial/public-vs-private-access-specifiers/ |
|
| 161 | + * https://www.learncpp.com/cpp-tutorial/classes-and-class-members/\ |
|
| 162 | + * https://www.w3schools.com/cpp/cpp_classes.asp |
|
| 163 | + * https://www.w3schools.com/cpp/cpp_constructors.asp |
|
| 164 | + * https://www.geeksforgeeks.org/destructors-c/ |
|
| 165 | + * https://docs.microsoft.com/en-us/cpp/cpp/value-types-modern-cpp?view=msvc-160 |
|
| 166 | + * https://ofstack.com/C++/9644/example-analysis-of-access-control-in-c++-inheritance.html |
|
| 167 | + * https://www.w3schools.com/cpp/cpp_oop.asp |
|
| 168 | + * https://www.w3schools.com/cpp/cpp_class_methods.asp |
|
| 169 | + * https://www.geekboots.com/story/10-interesting-stories-about-c |
|
| 170 | + * https://www.tutorialspoint.com/difference-between-c-and-cplusplus |
|
| 171 | + |
|
| 172 | +## SUBMISSION |
|
| 173 | + |
|
| 174 | +I'll be looking for the following: |
|
| 175 | + |
|
| 176 | +``` |
|
| 177 | +312:oop0:final tally of results (312/312) |
|
| 178 | +*:oop0:no compiler messages, program compiles and runs without issue [62/62] |
|
| 179 | +*:oop0:specified functionality is implemented [62/62] |
|
| 180 | +*:oop0:utilizes classes [64/64] |
|
| 181 | +*:oop0:utilizes access control, including private member data [64/64] |
|
| 182 | +*:oop0:demonstrates use of Object Oriented Programming [62/62] |
|
| 183 | +``` |
|
| 184 | + |
|
| 185 | +Additionally: |
|
| 186 | + * Solutions not abiding by **SPIRIT** of project will be subject to a 50% overall deduction |
|
| 187 | + * Solutions not utilizing descriptive why and how **COMMENTS** will be subject to a 50% overall deduction |
|
| 188 | + * Solutions not utilizing **INDENTATION** to promote scope and clarity will be subject to a 50% overall deduction |
|
| 189 | + * Solutions lacking **ORGANIZATION** and are not easy to read (within 90 char width) are subject to a 50% overall deduction |
haas/fall2026/cprog/projects/sof0.md
| ... | ... | @@ -0,0 +1,374 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: SQUARES OF FIVE (sof0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To implement a programmatic solution (ie simulation) of a real life |
|
| 8 | +process: the mental math trick of computing the square of any number |
|
| 9 | +ending with 5. |
|
| 10 | + |
|
| 11 | +The allure of using (and learning) a programming language is to be able |
|
| 12 | +to effectively use it to solve problems, which in and of themselves are |
|
| 13 | +simulations of some process we can do in "the real world". |
|
| 14 | + |
|
| 15 | +In this case, we will be writing a program which will implement the |
|
| 16 | +mental math techniques for computing the square of any one, two-, or |
|
| 17 | +three-digit number that ends with 5. |
|
| 18 | + |
|
| 19 | +There are other (perhaps more direct) means of performing this task, but |
|
| 20 | +that is not the objective here: you are to implement your solution |
|
| 21 | +adhering to the process described herein, which will expose you to |
|
| 22 | +important programmatic and problem solving details. |
|
| 23 | + |
|
| 24 | +## BACKGROUND |
|
| 25 | + |
|
| 26 | +Mental Math constitutes an intersection of mental techniques and math- |
|
| 27 | +instead of utilizing a purely math-only solution, textual manipulations |
|
| 28 | +or simplifications in the computational process may take place enabling |
|
| 29 | +an individual to, once having learned the process, solve such problems in |
|
| 30 | +their head, and typically without the use of a calculating device. |
|
| 31 | + |
|
| 32 | +The process in this case is one of numeric manipulation and simple |
|
| 33 | +(reduced) multiplication. To wit: |
|
| 34 | + |
|
| 35 | +### SQUARING A VALUE |
|
| 36 | + |
|
| 37 | +Squaring is essentially multiplying a number by itself- |
|
| 38 | + |
|
| 39 | + * `5` squared is `5*5` or `25` |
|
| 40 | + * `8` squared is `8*8` or `64` |
|
| 41 | + |
|
| 42 | +While not outwardly a difficult procedure, the nature of multiplying |
|
| 43 | +multiple digit numbers in your head can quickly result in more steps (and |
|
| 44 | +more steps means more time, if doing things the traditional way). |
|
| 45 | + |
|
| 46 | +Finding a shortcut through this process enables it to remain solidly |
|
| 47 | +within the realm of mental math, and makes for a good algorithm to |
|
| 48 | +practice implementing on the computer. |
|
| 49 | + |
|
| 50 | +This particular trick relies on a subset of the squares: those ending |
|
| 51 | +with a 5 (a five in the ones place). |
|
| 52 | + |
|
| 53 | +The implementational scope of this trick will be just values of one-, |
|
| 54 | +two-, and three-digits ending with 5: |
|
| 55 | + |
|
| 56 | + * 5 |
|
| 57 | + * 15 |
|
| 58 | + * 25 |
|
| 59 | + * 35 |
|
| 60 | + * 45 |
|
| 61 | + * 55 |
|
| 62 | + * 65 |
|
| 63 | + * 75 |
|
| 64 | + * 85 |
|
| 65 | + * 95 |
|
| 66 | + * 105 |
|
| 67 | + * 115 |
|
| 68 | + * 125 |
|
| 69 | + * ... |
|
| 70 | + * 235 |
|
| 71 | + * 245 |
|
| 72 | + * ... |
|
| 73 | + * 485 |
|
| 74 | + * 495 |
|
| 75 | + * 505 |
|
| 76 | + * ... |
|
| 77 | + * 995 |
|
| 78 | + |
|
| 79 | +### SQUARING VALUES ENDING WITH 5 |
|
| 80 | + |
|
| 81 | +The trick here is two-fold. First, we separate the one's place 5 from the |
|
| 82 | +rest of the number (which can be accomplished in our mind's easily |
|
| 83 | +enough, but on the computer we must resort to some math). |
|
| 84 | + |
|
| 85 | +We then take that isolated five and square it; we'll get 25. That is how |
|
| 86 | +our result will end (so bam! we now have our tens and ones place already |
|
| 87 | +solved) |
|
| 88 | + |
|
| 89 | +Next, we take the remaining digits of the original value, and multiply it |
|
| 90 | +by its increment: |
|
| 91 | + |
|
| 92 | + * 1's increment (1+1) is 2, so `1*2` |
|
| 93 | + * 2's increment (2+1) is 3, so `2*3` |
|
| 94 | + * 3's increment (3+1) is 4, so `3*4` |
|
| 95 | + * 4's increment (4+1) is 5, so `4*5` |
|
| 96 | + * ... |
|
| 97 | + * 9's increment (9+1) is 10, so `9*10` |
|
| 98 | + |
|
| 99 | +We take this result and append the 25 after it. |
|
| 100 | + |
|
| 101 | +For example: |
|
| 102 | + |
|
| 103 | +``` |
|
| 104 | +15 * 15 = 1*(1+1) 5*5 |
|
| 105 | + = 1*2 5*5 |
|
| 106 | + = 2 25 |
|
| 107 | + = 225 |
|
| 108 | +``` |
|
| 109 | + |
|
| 110 | +... and ... |
|
| 111 | + |
|
| 112 | +``` |
|
| 113 | +75 * 75 = 7*(7+1) 5*5 |
|
| 114 | + = 7*8 5*5 |
|
| 115 | + = 56 25 |
|
| 116 | + = 5625 |
|
| 117 | +``` |
|
| 118 | + |
|
| 119 | +For a single digit number like 5, when you take the 5 away, what do you |
|
| 120 | +get? **ZERO**. Zero times anything is zero, so the result is 0 25, or 25 |
|
| 121 | +(ie this process still works). |
|
| 122 | + |
|
| 123 | +For three digit numbers like 105, we have 10, and its increment is 11, so |
|
| 124 | +10 x 11 = 110. |
|
| 125 | + |
|
| 126 | +``` |
|
| 127 | +105 * 105 = 10*(10+1) 5*5 |
|
| 128 | + = 10*11 5*5 |
|
| 129 | + = 110 25 |
|
| 130 | + = 11025 |
|
| 131 | +``` |
|
| 132 | + |
|
| 133 | +## GRABIT |
|
| 134 | + |
|
| 135 | +I have prepared a `grabit` for resources related to this project. To |
|
| 136 | +obtain it: |
|
| 137 | + |
|
| 138 | +``` |
|
| 139 | +lab46:~/src/SEMESTER/DESIG$ grabit DESIG sof0 |
|
| 140 | +make: Entering directory '/var/public/SEMESTER/DESIG/sof0' |
|
| 141 | +'/var/public/SEMESTER/DESIG/sof0/Makefile' -> '/home/user/src/SEMESTER/DESIG/sof0/Makefile' |
|
| 142 | +'/var/public/SEMESTER/DESIG/sof0/sof0.c' -> '/home/user/src/SEMESTER/DESIG/sof0/sof0.c' |
|
| 143 | +make: Leaving directory '/var/public/SEMESTER/DESIG/sof0' |
|
| 144 | +lab46:~/src/SEMESTER/DESIG$ |
|
| 145 | +``` |
|
| 146 | + |
|
| 147 | +At which point you can change into the newly created and populated |
|
| 148 | +`sof0` directory. |
|
| 149 | + |
|
| 150 | +Be sure, using **git**, to **add**, **commit**, and **push** this to your |
|
| 151 | +lab46 clone of your repository. |
|
| 152 | + |
|
| 153 | +Then, if working on your pi/system, **git pull** to get the files |
|
| 154 | +available there, or continue working on it on lab46. |
|
| 155 | + |
|
| 156 | +## PROGRAM |
|
| 157 | + |
|
| 158 | +It is your task to write the program that will use the above method to |
|
| 159 | +compute the square of the input value ending with a 5 (you are to input |
|
| 160 | +the entire number, including the 5 at the end). |
|
| 161 | + |
|
| 162 | +Your program should: |
|
| 163 | + * prompt the user for the number (input) |
|
| 164 | + * input number as an unsigned short integer |
|
| 165 | + * perform the task (process) |
|
| 166 | + * isolate one's digit mathematically, store in a variable (unsigned short int) |
|
| 167 | + * isolate remaining digits mathematically, store in another variable (unsigned short int) |
|
| 168 | + * perform the algorithm on the two pieces, storing their results in two separate variables (of type unsigned short int) |
|
| 169 | + * display the final value (output) |
|
| 170 | + * display the beginning and ending parts together (but stored in separate variables) |
|
| 171 | + * display the resulting number to STDOUT (right-justified in a space supporting the largest possible value -- see output example below) |
|
| 172 | + * display any supporting text to STDERR (display of source values left-justified in a space supporting 3-digit values -- see output example below). |
|
| 173 | + * because we have not officially learned how to do selection/have the computer react to conditions, please implement with the assumption that the user will ALWAYS input a correct value. Do not worry about having to check for invalid or illegal input values (I will not be checking for such when I evaluate your project). |
|
| 174 | + |
|
| 175 | +## COMPILING |
|
| 176 | + |
|
| 177 | +The compilation process for working with your source code is as follows: |
|
| 178 | + |
|
| 179 | +``` |
|
| 180 | +lab46:~/src/SEMESTER/cprog/sof0$ gcc -Wall --std=gnu18 -o sof0 sof0.c |
|
| 181 | +lab46:~/src/SEMESTER/cprog/sof0$ |
|
| 182 | +``` |
|
| 183 | + |
|
| 184 | +Assuming there are no syntax errors or warnings, and everything compiled |
|
| 185 | +correctly, you should just get your prompt back. In the event of |
|
| 186 | +problems, the compiler will be sure to tell you about them. |
|
| 187 | + |
|
| 188 | +Conceptually, the arrangement is as follows: |
|
| 189 | + |
|
| 190 | +``` |
|
| 191 | +gcc -Wall --std=gnu18 -o BINARYFILE SOURCEFILE |
|
| 192 | +``` |
|
| 193 | + |
|
| 194 | +The `BINARYFILE` comes **immediately after** the **-o**, **NOT** the |
|
| 195 | +`SOURCEFILE` (the source file must never **immediately** follow a |
|
| 196 | +**-o**). It can precede, and such is perfectly valid (especially if you |
|
| 197 | +feel that way more intuitive). |
|
| 198 | + |
|
| 199 | +The `-Wall` (treat all warnings as errors, increase general verbosity |
|
| 200 | +about warnings) and `--std=gnu18` (switch compiler to use a newer |
|
| 201 | +standard of the C language, with GNU extensions) are options given to the |
|
| 202 | +compiler. |
|
| 203 | + |
|
| 204 | +## EXECUTION |
|
| 205 | + |
|
| 206 | +To execute your binary, we need to specify a path to it, so we use |
|
| 207 | +**./**, which basically references the current directory: |
|
| 208 | + |
|
| 209 | +``` |
|
| 210 | +lab46:~/src/SEMESTER/cprog/sof0$ ./sof0 |
|
| 211 | +Enter value: 75 |
|
| 212 | +75 x 75 = 5625 |
|
| 213 | +lab46:~/src/SEMESTER/cprog/sof0$ |
|
| 214 | +``` |
|
| 215 | + |
|
| 216 | +The execution of the program is short and simple- obtain the input, do |
|
| 217 | +the processing, produce the output, and then terminate. |
|
| 218 | + |
|
| 219 | +Note how the two "75" values are left-justified within a 3-space slot |
|
| 220 | +(with the multiplication 'x' and equal sign '=' being padded with a space |
|
| 221 | +on either side). This information should all be displayed to STDERR. |
|
| 222 | + |
|
| 223 | +Similarly, here's an example of 105x105: |
|
| 224 | + |
|
| 225 | +``` |
|
| 226 | +lab46:~/src/SEMESTER/cprog/sof0$ ./sof0 |
|
| 227 | +Enter value: 105 |
|
| 228 | +105 x 105 = 11025 |
|
| 229 | +lab46:~/src/SEMESTER/cprog/sof0$ |
|
| 230 | +``` |
|
| 231 | + |
|
| 232 | +The 'x' and '=' padding persists, but because we're squaring a 3-digit |
|
| 233 | +value vs. a 2-digit value, we occupy the entire allocated space on the |
|
| 234 | +screen. |
|
| 235 | + |
|
| 236 | +If you'd like to verify successful output to STDOUT/STDERR, you can |
|
| 237 | +perform the following tests. First, verify that the answer (and ONLY the |
|
| 238 | +answer), is being sent to STDOUT -- we do this by eliminating STDERR |
|
| 239 | +entirely: |
|
| 240 | + |
|
| 241 | +``` |
|
| 242 | +lab46:~/src/SEMESTER/cprog/sof0$ ./sof0 2> /dev/null <<< 105 |
|
| 243 | + 11025 |
|
| 244 | +lab46:~/src/SEMESTER/cprog/sof0$ |
|
| 245 | +``` |
|
| 246 | + |
|
| 247 | +What we are doing here is two-fold: |
|
| 248 | + |
|
| 249 | + * We are using command-line I/O redirection to redirect STDERR (which is bound to file descriptor #2) to the system bit-bucket. |
|
| 250 | + * We are "redirecting" STDIN using a **here string**, providing the program's input of **105** right on the command-line at time of execution. |
|
| 251 | + |
|
| 252 | +Similarly, if we were to eliminate STDOUT entirely (for verifying STDERR |
|
| 253 | +output): |
|
| 254 | + |
|
| 255 | +``` |
|
| 256 | +lab46:~/src/SEMESTER/cprog/sof0$ ./sof0 1> /dev/null |
|
| 257 | +Enter value: 75 |
|
| 258 | +75 x 75 = lab46:~/src/SEMESTER/cprog/sof0$ |
|
| 259 | +``` |
|
| 260 | + |
|
| 261 | +What we are doing here: |
|
| 262 | + |
|
| 263 | + * We are using command-line I/O redirection to redirect STDOUT (which is bound to file descriptor #1) to the system bit-bucket. |
|
| 264 | + |
|
| 265 | +## VERIFICATION |
|
| 266 | + |
|
| 267 | +One of the tests I will perform for output compliance of your code will |
|
| 268 | +involve comparing your program's output against a range of input values, |
|
| 269 | +to see if they all output in conformance with project specifications. |
|
| 270 | + |
|
| 271 | +I will make use of a checksum to verify exactness. |
|
| 272 | + |
|
| 273 | +You will need to run this from your sof0 project directory with a |
|
| 274 | +compiled and operational binary by the name of **sof0**. |
|
| 275 | + |
|
| 276 | +You can check your project by typing in the following at the prompt: |
|
| 277 | + |
|
| 278 | +``` |
|
| 279 | +lab46:~/src/SEMESTER/cprog/sof0$ pchk cprog sof0 |
|
| 280 | +``` |
|
| 281 | + |
|
| 282 | +If all aligns, you will see this: |
|
| 283 | + |
|
| 284 | +``` |
|
| 285 | +================================================== |
|
| 286 | += CPROG sof0 project output validation tool = |
|
| 287 | +================================================== |
|
| 288 | +sof0 checksum is: 822a47fb2a45845500b6c10878045bd5 |
|
| 289 | +your checksum is: 822a47fb2a45845500b6c10878045bd5 |
|
| 290 | +================================================== |
|
| 291 | + verification: SUCCESS! |
|
| 292 | +================================================== |
|
| 293 | +``` |
|
| 294 | + |
|
| 295 | +If something is off, your checksum will not match the sof0 checksum, and |
|
| 296 | +verification will instead say "**MISMATCH**", like follows (note that a |
|
| 297 | +mismatched checksum can be anything, and likely not what is seen in this |
|
| 298 | +example): |
|
| 299 | + |
|
| 300 | +``` |
|
| 301 | +================================================== |
|
| 302 | += CPROG sof0 project output validation tool = |
|
| 303 | +================================================== |
|
| 304 | +sof0 checksum is: 822a47fb2a45845500b6c10878045bd5 |
|
| 305 | +your checksum is: 92af264c86823a61529948caaeac53e0 |
|
| 306 | +================================================== |
|
| 307 | + verification: MISMATCH |
|
| 308 | +================================================== |
|
| 309 | +``` |
|
| 310 | + |
|
| 311 | +## QUESTIONS FOR CONSIDERATION |
|
| 312 | + |
|
| 313 | +These are things I'd like you to contemplate, even use as potential |
|
| 314 | +material on your weekly journal entry. The more you think about and |
|
| 315 | +understand the problem, the better your ability to solve it and other |
|
| 316 | +problems. |
|
| 317 | + |
|
| 318 | + * Why/how does this trick work for 1-digit numbers? |
|
| 319 | + * Considering our 1-, 2-, and 3-digit domain restriction for this project, how many candidate values are there for input? |
|
| 320 | + * What is the smallest input value? |
|
| 321 | + * What is the largest input value? |
|
| 322 | + * How many input values are there that end in **5**? |
|
| 323 | + * What is the largest square that can be calculated given the project input restrictions? |
|
| 324 | + * How many digits is the largest square? |
|
| 325 | + * How can knowing how many digits the largest square is help you implement your solution? |
|
| 326 | + |
|
| 327 | +## SUBMISSION |
|
| 328 | + |
|
| 329 | +To successfully complete this project, the following criteria must be |
|
| 330 | +met: |
|
| 331 | + |
|
| 332 | + * Code must compile/execute cleanly (no notes, warnings, nor errors) |
|
| 333 | + * Code must be nicely and consistently indented |
|
| 334 | + * Code must be well commented |
|
| 335 | + * Do NOT double space your code. Group like statements together. |
|
| 336 | + * Track/version the source code in your private semester repository |
|
| 337 | + * Submit a copy of your source code to me using the **submit** tool |
|
| 338 | + |
|
| 339 | +To submit this program to me using the **submit** tool, run the following |
|
| 340 | +command at your LAB46 prompt: |
|
| 341 | + |
|
| 342 | +``` |
|
| 343 | +lab46:~/src/SEMESTER/cprog/sof0$ make submit |
|
| 344 | +``` |
|
| 345 | + |
|
| 346 | +You should get some sort of confirmation indicating successful submission |
|
| 347 | +if all went according to plan. If not, check for typos and or locational |
|
| 348 | +mismatches. |
|
| 349 | + |
|
| 350 | +What I'll be looking for: |
|
| 351 | + |
|
| 352 | +### RUBRIC |
|
| 353 | + |
|
| 354 | +I'll be evaluating the project based on the following criteria: |
|
| 355 | + |
|
| 356 | +``` |
|
| 357 | +130:sof0:final tally of results (130/130) |
|
| 358 | +*:sof0:grabit the code on lab46 by Sunday before deadline [13/13] |
|
| 359 | +*:sof0:code is pushed to private semester repository [13/13] |
|
| 360 | +*:sof0:proper output formatting per specifications [26/26] |
|
| 361 | +*:sof0:clean compile, no compiler messages [26/26] |
|
| 362 | +*:sof0:program conforms to project specifications [26/26] |
|
| 363 | +*:sof0:progrm passes verification checks [26/26] |
|
| 364 | +``` |
|
| 365 | + |
|
| 366 | +NOTE: The spirit of program implementation includes your process |
|
| 367 | +using the mental math approach, not a more seemingly-straightforward |
|
| 368 | +computational approach, or one given to you out of context by AI. |
|
| 369 | + |
|
| 370 | +Additionally: |
|
| 371 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 372 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 373 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 374 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/unix/projects/dac0.md
| ... | ... | @@ -0,0 +1,310 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: DATA ARCHIVING AND COMPRESSION (dac0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Reference technical documentation to locate and operate particular tools |
|
| 8 | +to aid you in accomplishing a task. |
|
| 9 | + |
|
| 10 | +## PREREQUISITES |
|
| 11 | + |
|
| 12 | +To successfully accomplish/perform this project, the listed |
|
| 13 | +resources/experiences need to be consulted/achieved: |
|
| 14 | + |
|
| 15 | + * ability to read the manual pages and use the information therein |
|
| 16 | + * ability to copy, move, and list files |
|
| 17 | + * ability to navigate around the filesystem |
|
| 18 | + |
|
| 19 | +## NO GRABIT |
|
| 20 | + |
|
| 21 | +As part of this activity is to test your ability to navigate around the |
|
| 22 | +filesystem and manipulate files on your own, there is no grabit |
|
| 23 | +configured for this project. |
|
| 24 | + |
|
| 25 | +Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your |
|
| 26 | +project files back into your repository. |
|
| 27 | + |
|
| 28 | +## TOOLBOX |
|
| 29 | + |
|
| 30 | +It would be especially useful to review the manual pages or any |
|
| 31 | +documentation on the following resources: |
|
| 32 | + |
|
| 33 | + * `cp`(1) |
|
| 34 | + * `mv`(1) |
|
| 35 | + * `ls`(1) |
|
| 36 | + * `mkdir`(1) |
|
| 37 | + * `tar`(1) |
|
| 38 | + * `xz`(1) |
|
| 39 | + * `gzip`(1) |
|
| 40 | + * `bzip2`(1) |
|
| 41 | + * `zip`(1) |
|
| 42 | + * `tac`(1) |
|
| 43 | + * `rev`(1) |
|
| 44 | + * `cat`(1) |
|
| 45 | + * `file`(1) |
|
| 46 | + * `uudecode`(1) |
|
| 47 | + * `md5sum`(1) |
|
| 48 | + |
|
| 49 | +## BACKGROUND |
|
| 50 | + |
|
| 51 | +When we talk about archives, there are commonly two separate actions |
|
| 52 | +taking place. Sometimes they are intertwined, others they represent |
|
| 53 | +discrete steps. |
|
| 54 | + |
|
| 55 | +They are: |
|
| 56 | + |
|
| 57 | + * archiving / extracting |
|
| 58 | + * compression / decompression |
|
| 59 | + |
|
| 60 | +Archives are merely a manifestation of a common computing concept: a |
|
| 61 | +container. |
|
| 62 | + |
|
| 63 | +Containers encapsulate things; in this case- files. And the fact that |
|
| 64 | +UNIX tries to make everything a file really enhances the viability of |
|
| 65 | +this ability. |
|
| 66 | + |
|
| 67 | +Compression, on the other hand, is an action performed on a single file. |
|
| 68 | +Utilizing various algorithms, we accomplish a sort of "more in less"... |
|
| 69 | +we can take the data present and cram it into a smaller box (file)... |
|
| 70 | +where the aim is to take up less storage on the filesystem (also makes |
|
| 71 | +copying easier). |
|
| 72 | + |
|
| 73 | + |
|
| 74 | +There are many compression algorithms in existence. There are commonly two categories of compression algorithm: |
|
| 75 | + |
|
| 76 | + * [lossless compression](http://en.wikipedia.org/wiki/Lossless_data_compression) - no data is lost as a part of the compression process |
|
| 77 | + * [lossy compression](http://en.wikipedia.org/wiki/Lossy_data_compression) - unnecessary data is discarded as part of the compression process |
|
| 78 | + |
|
| 79 | +Wikipedia has categories identifying various algorithms implemented for |
|
| 80 | +both **lossless** and **lossy** compression algorithms. |
|
| 81 | + |
|
| 82 | +Where confusion may set in is when a tool combines the actions of |
|
| 83 | +archival AND compression. But if you think about it, even in such cases, |
|
| 84 | +we always end up with one file, and that file is compressed (unless we |
|
| 85 | +have a concatenation of separately compressed files into a single file. |
|
| 86 | + |
|
| 87 | +Archives are useful in that they let us pack items together. If something |
|
| 88 | +needs 100 files, making a copy of that, or copying it/install it onto |
|
| 89 | +another system would be made more complex if we had to deal with each of |
|
| 90 | +those files individually. Archives simplify the problem in that they can |
|
| 91 | +provide us all those files, all contained within a single file (lessening |
|
| 92 | +opportunities for error). So, archives make our lives easier. |
|
| 93 | + |
|
| 94 | +## ON YOUR DEVELOPMENT SYSTEM |
|
| 95 | + |
|
| 96 | +Once you obtain the project files on the LAB46 SHELL SYSTEM, and transfer |
|
| 97 | +them over to your development system (you can add them to your private |
|
| 98 | +repository), you will want to perform the project off of lab46, as you |
|
| 99 | +may need to install additional packages and tools to process the data. |
|
| 100 | + |
|
| 101 | +On your development system, I want you to do the following: |
|
| 102 | + |
|
| 103 | + * Figure out the format of the files, and read up on the available tools for manipulating them |
|
| 104 | + * Install any needed tools to accomplish the task of accessing the information contained within |
|
| 105 | + * Extract the contents of the archive and study it (contents will extract to the current working directory, so you WILL want to be in a custom project directory) |
|
| 106 | + * Analyze the files extracted from the archive. Each file will ultimately be contextually readable plain text (in English), but some may be encoded or compressed or otherwise manipulated and will need further processing to get to the final readable state. |
|
| 107 | + * Once in their readable states, name the files **a**, **b**, **c**, **d**, **e**, **f**, **g**, **h**, in order of their file sizes (in bytes), from least to greatest. |
|
| 108 | + * Place these single-lettered files in a new **tar** archive called **result.tar** (files should be added to the archive in the current directory, do not embed any directory information in the archive). |
|
| 109 | + * Compress it (using **maximum** compression) with **gzip**(**1**); it should now be called **result.tar.gz** |
|
| 110 | + * you are going to submit this archive |
|
| 111 | + * In addition to the created archive, you will also submit a text file named **dac0.steps** which will contain step-by-step command-lines used to copy, extract, manipulate, rename, create a new archive and compress **result.tar.gz** (document from the point of having the copied files in place on your development system). |
|
| 112 | + * you do NOT need to include any repository, verify, or submit commands, JUST those steps for accomplishing the core task of the files in the project to stated specifications. |
|
| 113 | + * The file should JUST contain the exact commands you used, in order from start to finish. If you'd like to add any additional commentary, prefix it with a # sign. |
|
| 114 | + * Commands should be left justified, one command-line per line (lines can wrap). |
|
| 115 | + * Do NOT number your steps. Just place the command-line incantations utilized, one after the other. |
|
| 116 | + |
|
| 117 | +## PROCESS |
|
| 118 | + |
|
| 119 | +On the system hosting the needed resources, egress from your home |
|
| 120 | +directory and navigate to the UNIX PUBLIC DIRECTORY, locate the |
|
| 121 | +subdirectory for this project and navigate there. |
|
| 122 | + |
|
| 123 | +Assess the layout of files. What type of files are here? Are they named |
|
| 124 | +in a manner so as to indicate a specific course of action? |
|
| 125 | + |
|
| 126 | +Once you locate your files, proceed to copy them into your home |
|
| 127 | +directory, into a custom project subdirectory you've made, ideally in |
|
| 128 | +your repository. |
|
| 129 | + |
|
| 130 | +Ingress to that destination, ensure said files have been included into |
|
| 131 | +your repository. Do note: your repository by default may be configured to |
|
| 132 | +ignore many archive files. To override this, add them specifically by |
|
| 133 | +name. |
|
| 134 | + |
|
| 135 | +Transition to your development system, navigate into your repository. |
|
| 136 | +Obtain the files, and verify they are present. |
|
| 137 | + |
|
| 138 | +Focusing on one archive at a time: |
|
| 139 | + |
|
| 140 | + * what type of archive is it? |
|
| 141 | + * what tools might be needed to extract and/or decompress it? |
|
| 142 | + * reference the manual page(s) for any tools in question, determine any options that need to be applied. |
|
| 143 | + * attempt to extract files from the archive. Did it work? How can you tell what new additions there are? (Do note: many of these tools have options to enable *verbose* operation, which might prove particularly helpful in this endeavour). |
|
| 144 | + * one at a time, investigate any new files: |
|
| 145 | + * is it viewable? |
|
| 146 | + * is it readable? |
|
| 147 | + * if not, is there something that looks out of sorts that you could manipulate to correct it? |
|
| 148 | + * is it contextually readable, english text? |
|
| 149 | + * take note of the file size |
|
| 150 | + * as you accumulate processed files, proceed to order them by file size |
|
| 151 | + |
|
| 152 | +## VERIFICATION |
|
| 153 | + |
|
| 154 | +One of the tests I will perform for output compliance of your code will |
|
| 155 | +involve comparing your program's output against a range of input values, |
|
| 156 | +to see if they all output in conformance with project specifications. |
|
| 157 | + |
|
| 158 | +I will make use of a checksum to verify exactness. |
|
| 159 | + |
|
| 160 | +You will need to run this from your **dac0 project directory**, where |
|
| 161 | +your individual `a`-`h` files are located. |
|
| 162 | + |
|
| 163 | +You can check your project by typing in the following at the prompt (on |
|
| 164 | +lab46): |
|
| 165 | + |
|
| 166 | +``` |
|
| 167 | +lab46:~/src/SEMESTER/unix/dac0$ filechk unix dac0 |
|
| 168 | +``` |
|
| 169 | + |
|
| 170 | +If all aligns, you will see this: |
|
| 171 | + |
|
| 172 | +``` |
|
| 173 | +==========unix/dac0 whole file comparison========================================= |
|
| 174 | + For the file: a |
|
| 175 | + you want: cca000c9cb8a5c134bed61154a7907ba |
|
| 176 | + you have: cca000c9cb8a5c134bed61154a7907ba MATCH |
|
| 177 | + |
|
| 178 | + For the file: b |
|
| 179 | + you want: c8136ca761229bad59497021a8f425af |
|
| 180 | + you have: c8136ca761229bad59497021a8f425af MATCH |
|
| 181 | + |
|
| 182 | + For the file: c |
|
| 183 | + you want: d6db0da4b084fff4b255ae7a4e95ed62 |
|
| 184 | + you have: d6db0da4b084fff4b255ae7a4e95ed62 MATCH |
|
| 185 | + |
|
| 186 | + For the file: d |
|
| 187 | + you want: dadd5272203fa77b80f26cf355e6e833 |
|
| 188 | + you have: dadd5272203fa77b80f26cf355e6e833 MATCH |
|
| 189 | + |
|
| 190 | + For the file: e |
|
| 191 | + you want: af095aeaaf55a8a3b351a921baebc9e7 |
|
| 192 | + you have: af095aeaaf55a8a3b351a921baebc9e7 MATCH |
|
| 193 | + |
|
| 194 | + For the file: f |
|
| 195 | + you want: 84d0fd81532fac6c743c8054f76f0270 |
|
| 196 | + you have: 84d0fd81532fac6c743c8054f76f0270 MATCH |
|
| 197 | + |
|
| 198 | + For the file: g |
|
| 199 | + you want: c36a56a9ab8190e4d007bd16e377639a |
|
| 200 | + you have: c36a56a9ab8190e4d007bd16e377639a MATCH |
|
| 201 | + |
|
| 202 | + For the file: h |
|
| 203 | + you want: 226c53b09f112cf7323cd5263302ea95 |
|
| 204 | + you have: 226c53b09f112cf7323cd5263302ea95 MATCH |
|
| 205 | + |
|
| 206 | +``` |
|
| 207 | + |
|
| 208 | +If something is off, your checksum will not match the dac0 checksum, and |
|
| 209 | +verification will instead say "**MISMATCH**", like follows (note that a |
|
| 210 | +mismatched checksum can be anything, and likely not what is seen in this |
|
| 211 | +example): |
|
| 212 | + |
|
| 213 | +``` |
|
| 214 | +==========unix/dac0 whole file comparison========================================= |
|
| 215 | + For the file: a |
|
| 216 | + you want: cca000c9cb8a5c134bed61154a7907ba |
|
| 217 | + you have: cca000c9cb8a5c134bed61154a7907ba MATCH |
|
| 218 | + |
|
| 219 | + For the file: b |
|
| 220 | + you want: d8136ca761229bad59497021a8f425af |
|
| 221 | + you have: c8136ca761229bad59497021a8f425af MISMATCH |
|
| 222 | + |
|
| 223 | + For the file: c |
|
| 224 | + you want: d6db0da4b084fff4b255ae7a4e95ed62 |
|
| 225 | + you have: d6db0da4b084fff4b255ae7a4e95ed62 MATCH |
|
| 226 | + |
|
| 227 | + For the file: d |
|
| 228 | + you want: dadd5272203fa77b80f26cf355e6e833 |
|
| 229 | + you have: dadd5272203fa77b80f26cf355e6e833 MATCH |
|
| 230 | + |
|
| 231 | + For the file: e |
|
| 232 | + you want: af095aeaaf55a8a3b351a921baebc9e7 |
|
| 233 | + you have: af095aeaaf55a8a3b351a921baebc9e7 MATCH |
|
| 234 | + |
|
| 235 | + For the file: f |
|
| 236 | + you want: 84d0fd81532fac6c743c8054f76f0270 |
|
| 237 | + you have: 84d0fd81532fac6c743c8054f76f0270 MATCH |
|
| 238 | + |
|
| 239 | + For the file: g |
|
| 240 | + you want: d36a56a9ab8190e4d007bd16e377639a |
|
| 241 | + you have: c36a56a9ab8190e4d007bd16e377639a MISMATCH |
|
| 242 | + |
|
| 243 | + For the file: h |
|
| 244 | + you want: 226c53b09f112cf7323cd5263302ea95 |
|
| 245 | + you have: 226c53b09f112cf7323cd5263302ea95 MATCH |
|
| 246 | + |
|
| 247 | +``` |
|
| 248 | + |
|
| 249 | +## SUBMISSION |
|
| 250 | + |
|
| 251 | +To be successful in this project, the following criteria (or their |
|
| 252 | +equivalent) must be met: |
|
| 253 | + |
|
| 254 | + * Project must be submit on time, by the deadline. |
|
| 255 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 256 | + * Track/version your projects files in your private semester repository |
|
| 257 | + * Submit a copy of your final archive to me using the **submit** tool. |
|
| 258 | + |
|
| 259 | +### SUBMIT TOOL USAGE |
|
| 260 | + |
|
| 261 | +Let's say you have completed work on the project, and are ready to |
|
| 262 | +submit, you would do the following: |
|
| 263 | + |
|
| 264 | +``` |
|
| 265 | +lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN |
|
| 266 | +``` |
|
| 267 | + |
|
| 268 | +A less abstract instantiation of the above (to help you transition): |
|
| 269 | + |
|
| 270 | +``` |
|
| 271 | +lab46:~/src/SEMESTER/unix/dac0$ submit unix dac0 result.tar.gz dac0.steps |
|
| 272 | +Submitting unix project "dac0": |
|
| 273 | + -> result.tar.gz(OK) |
|
| 274 | + -> dac0.steps(OK) |
|
| 275 | + |
|
| 276 | +SUCCESSFULLY SUBMITTED |
|
| 277 | +``` |
|
| 278 | + |
|
| 279 | +You should get some sort of confirmation indicating successful submission |
|
| 280 | +if all went according to plan. If not, check for typos and or locational |
|
| 281 | +mismatches. |
|
| 282 | + |
|
| 283 | +## RUBRIC |
|
| 284 | + |
|
| 285 | +I'll be evaluating the project based on the following criteria: |
|
| 286 | + |
|
| 287 | +``` |
|
| 288 | +78:dac0:final tally of results (78/78) |
|
| 289 | +*:dac0:archive submitted [6/6] |
|
| 290 | +*:dac0:archive has correct name of result.tar.gz [6/6] |
|
| 291 | +*:dac0:archive is max compressed with gzip [6/6] |
|
| 292 | +*:dac0:archive is a tar archive [6/6] |
|
| 293 | +*:dac0:archive extracts into current directory [6/6] |
|
| 294 | +*:dac0:archive contains 8 english readable files [6/6] |
|
| 295 | +*:dac0:archived files are named a-h [6/6] |
|
| 296 | +*:dac0:archived files named in order of size [6/6] |
|
| 297 | +*:dac0:instructions submitted in text file [6/6] |
|
| 298 | +*:dac0:instructions in file named dac0.steps [6/6] |
|
| 299 | +*:dac0:dac0.steps contains list of instructions for accomplishing task [6/6] |
|
| 300 | +*:dac0:dac0.steps instructions are accurate and correct [6/6] |
|
| 301 | +*:dac0:dac0.steps any extra information after hash mark [6/6] |
|
| 302 | +``` |
|
| 303 | + |
|
| 304 | +### ADDITIONALLY |
|
| 305 | + |
|
| 306 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 307 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 308 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 309 | + * 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 |
|
| 310 | + |
haas/fall2026/unix/projects/fwg0.md
| ... | ... | @@ -0,0 +1,194 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Obtain the latest stable release source code, or latest repository code, |
|
| 8 | +of the `Vircon32` Fantasy Console, along with its `DevTools`, and modify |
|
| 9 | +the provided code to display a sprite, move it around the screen, and |
|
| 10 | +detect screen bounds. |
|
| 11 | + |
|
| 12 | +## TASK |
|
| 13 | + |
|
| 14 | +Obtain and install on your development system the latest stable release, |
|
| 15 | +or latest version of the repository code, of the `Vircon32` Fantasy |
|
| 16 | +Console, along with its `DevTools` (C compiler). |
|
| 17 | + |
|
| 18 | +NOTE: Do **not** add the source code or binary code to `Vircon32` or |
|
| 19 | +`DevTools` to your repository! Process these outside of your repository. |
|
| 20 | +Once installed, your files specifically related to your modified code |
|
| 21 | +SHOULD be added to your repository. |
|
| 22 | + |
|
| 23 | +There is a `README` file in the base directory of the Vircon32 |
|
| 24 | +`ComputerSoftware` directory that includes build instructions. |
|
| 25 | + |
|
| 26 | +Verify that it works, by testing the grabit code in its initial state by |
|
| 27 | +ensuring the `DevTools` work when called (`compile`, `assemble`, and |
|
| 28 | +`packrom`), and of course running it in the `Vircon32` emulator. |
|
| 29 | + |
|
| 30 | +Then, modify the program according to the following criteria: |
|
| 31 | + |
|
| 32 | +## PROGRAM |
|
| 33 | + |
|
| 34 | +You are to write a Vircon32 C program that does the following: |
|
| 35 | + |
|
| 36 | + * displays some "sprite" of your choosing on the screen |
|
| 37 | + * moves based on the control of the first gamepad (left, right, up, down) |
|
| 38 | + * screen bounds detection and handling (barrier or wrap-around) |
|
| 39 | + |
|
| 40 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 41 | + |
|
| 42 | +While this isn't a "programming" course, it is one where we solve |
|
| 43 | +problems and learn to utilize available information. It is expected you |
|
| 44 | +make use of the Vircon32 API documentation along with asking questions on |
|
| 45 | +the DISCORD. |
|
| 46 | + |
|
| 47 | +## URLs |
|
| 48 | + |
|
| 49 | +The main Vircon32 site can be found [here](https://www.vircon32.com/), be |
|
| 50 | +sure to note the link to the Vircon32 API. |
|
| 51 | + |
|
| 52 | +The code can be found on the [Vircon32 ComputerSoftware GitHub |
|
| 53 | +repository](https://github.com/vircon32/ComputerSoftware/) |
|
| 54 | + |
|
| 55 | +I would recommend against checking out the tutorials: too many have |
|
| 56 | +gotten into trouble being influenced by the code, running into issues |
|
| 57 | +trying to conform to project specifications. |
|
| 58 | + |
|
| 59 | +## CARTRIDGE BUILD PROCESS |
|
| 60 | + |
|
| 61 | +You will want to create your own bash build script that will facilitate |
|
| 62 | +the build process from the steps laid out. You should be able to run your |
|
| 63 | +script and, all components being in order, produce a viable V32 file that |
|
| 64 | +can be played in the emulator. |
|
| 65 | + |
|
| 66 | +It should assume that the Vircon32 DevTools are present in your PATH. |
|
| 67 | + |
|
| 68 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 69 | +file as appropriate before building. |
|
| 70 | + |
|
| 71 | +### COMPILE |
|
| 72 | + |
|
| 73 | +First step is to compile the C code, which can be done with the following |
|
| 74 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 75 | + |
|
| 76 | +``` |
|
| 77 | +yoursystem:~/src/SEMESTER/unix/fwg0$ compile fwg0.c -o fwg0.asm |
|
| 78 | +``` |
|
| 79 | + |
|
| 80 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 81 | +code, which will then need to be assembled to machine code: |
|
| 82 | + |
|
| 83 | +### ASSEMBLE |
|
| 84 | + |
|
| 85 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 86 | +`assemble` DevTool to assemble the assembly: |
|
| 87 | + |
|
| 88 | +``` |
|
| 89 | +yoursystem:~/src/SEMESTER/unix/fwg0$ assemble fwg0.asm -o fwg0.vbin |
|
| 90 | +``` |
|
| 91 | + |
|
| 92 | +### IMAGE CONVERSTION |
|
| 93 | + |
|
| 94 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 95 | +format via the `png2vircon` tool: |
|
| 96 | + |
|
| 97 | +``` |
|
| 98 | +yoursystem:~/src/SEMESTER/unix/fwg0$ png2vircon background.png -o background.vtex |
|
| 99 | +yoursystem:~/src/SEMESTER/unix/fwg0$ png2vircon sprites.png -o sprites.vtex |
|
| 100 | +``` |
|
| 101 | + |
|
| 102 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 103 | +reference these textures: |
|
| 104 | + |
|
| 105 | +``` |
|
| 106 | + <binary path="fwg0.vbin" /> |
|
| 107 | + <textures> |
|
| 108 | + <texture path="background.vtex" /> |
|
| 109 | + <texture path="sprites.vtex" /> |
|
| 110 | + </textures> |
|
| 111 | +``` |
|
| 112 | + |
|
| 113 | +### AUDIO CONVERSION |
|
| 114 | + |
|
| 115 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 116 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 117 | + |
|
| 118 | +``` |
|
| 119 | +yoursystem:~/src/SEMESTER/unix/fwg0$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 120 | +yoursystem:~/src/SEMESTER/unix/fwg0$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 121 | +``` |
|
| 122 | + |
|
| 123 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 124 | +reference these sounds: |
|
| 125 | + |
|
| 126 | +``` |
|
| 127 | + <sounds> |
|
| 128 | + <sound path="backgroundmusic.vsnd" /> |
|
| 129 | + <sound path="soundfx.vsnd" /> |
|
| 130 | + </sounds> |
|
| 131 | +``` |
|
| 132 | + |
|
| 133 | +### PACKING THE ROM |
|
| 134 | + |
|
| 135 | +Once all the components have been built, you can pack them together into |
|
| 136 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 137 | + |
|
| 138 | +``` |
|
| 139 | +yoursystem:~/src/SEMESTER/unix/fwg0$ packrom fwg0.xml |
|
| 140 | +``` |
|
| 141 | + |
|
| 142 | +## SUBMISSION |
|
| 143 | + |
|
| 144 | +To be successful in this project, the following criteria (or their |
|
| 145 | +equivalent) must be met: |
|
| 146 | + |
|
| 147 | + * Project must be submit on time, by the deadline. |
|
| 148 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 149 | + * Executed programs must display in a manner similar to provided output |
|
| 150 | + * output formatted, where applicable, must match that of project requirements |
|
| 151 | + * Processing must be correct based on input given and output requested |
|
| 152 | + * Output, if applicable, must be correct based on values input |
|
| 153 | + * Code must be nicely and consistently indented |
|
| 154 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 155 | + * Code must be commented |
|
| 156 | + * Any "to be implemented" comments **MUST** be removed |
|
| 157 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 158 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 159 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 160 | + * Track/version the source code in your private semester repository |
|
| 161 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 162 | + |
|
| 163 | +### SUBMIT TOOL USAGE |
|
| 164 | + |
|
| 165 | +Let's say you have completed work on the project, and are ready to |
|
| 166 | +submit, you would do the following: |
|
| 167 | + |
|
| 168 | +``` |
|
| 169 | +lab46:~/src/SEMESTER/unix/fwg0$ make submit |
|
| 170 | +``` |
|
| 171 | + |
|
| 172 | +You should get some sort of confirmation indicating successful submission |
|
| 173 | +if all went according to plan. If not, check for typos and or locational |
|
| 174 | +mismatches. |
|
| 175 | + |
|
| 176 | +### RUBRIC |
|
| 177 | + |
|
| 178 | +I'll be evaluating the project based on the following criteria: |
|
| 179 | + |
|
| 180 | +``` |
|
| 181 | +260:fwg0:final tally of results (260/260) |
|
| 182 | +*:fwg0:code modified to meet project specifications [52/52] |
|
| 183 | +*:fwg0:screenshot or video posted to class DISCORD of game running [52/52] |
|
| 184 | +*:fwg0:source file, XML file, build script, and cartridge submit [52/52] |
|
| 185 | +*:fwg0:code compiles, cartridge builds with no warning or error [52/52] |
|
| 186 | +*:fwg0:committed project related changes to private semester repo [52/52] |
|
| 187 | +``` |
|
| 188 | + |
|
| 189 | +Additionally: |
|
| 190 | + |
|
| 191 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 192 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 193 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 194 | + * 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 |
haas/fall2026/unix/projects/gtf0.md
| ... | ... | @@ -0,0 +1,102 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: GRADE TO FIGURE OUT (gtf0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Throughout the semester, you have been, through the use of the text-based |
|
| 8 | +`sc` spreadsheet, computing your current grade in the class based on snap |
|
| 9 | +shots of data at the 4-, 8-, and 12- week intervals. |
|
| 10 | + |
|
| 11 | +Your aim with this project is to take your familiarity with manually |
|
| 12 | +performing that process, and automate it through the use of a shell |
|
| 13 | +script. |
|
| 14 | + |
|
| 15 | +## TASK |
|
| 16 | + |
|
| 17 | +Take one of your existing gfoX assignments and look at the spreadsheet |
|
| 18 | +file created. Not through `sc` itself, but instead, in a *text editor* |
|
| 19 | +(such as `vi`/`vim`). |
|
| 20 | + |
|
| 21 | +Take in the structure of the information, the format. The patterns of how |
|
| 22 | +the data progresses. |
|
| 23 | + |
|
| 24 | +Can you predict how things will progress and work? Can you automate those |
|
| 25 | +steps? |
|
| 26 | + |
|
| 27 | +Your aim is to create a **bash shell script** that will perform the work |
|
| 28 | +of reading from the **status** command output (be sure to be familiar |
|
| 29 | +with **grep**(1)), and have it construct a spreadsheet (in accordance |
|
| 30 | +with gfoX submission criteria) of your progress in the class, based on |
|
| 31 | +the particular gfoX instance (or week number given). |
|
| 32 | + |
|
| 33 | +You will want to make use of: |
|
| 34 | + |
|
| 35 | + * variables |
|
| 36 | + * command-line argument (via `$1`, etc.) |
|
| 37 | + * if statements / the `test` command (via `[`) |
|
| 38 | + * loops |
|
| 39 | + * I/O redirection |
|
| 40 | + * command expansion |
|
| 41 | + * regular expressions |
|
| 42 | + |
|
| 43 | +Again, the `sc`-compatible spreadsheet your script produces should be |
|
| 44 | +viewable in `sc`, and be in accordance with gfoX submission criteria (the |
|
| 45 | +idea is that you will be able to use it to submit `gfo2` when its time |
|
| 46 | +comes). |
|
| 47 | + |
|
| 48 | +## SUBMISSION |
|
| 49 | + |
|
| 50 | +To be successful in this project, the following criteria (or their |
|
| 51 | +equivalent) must be met: |
|
| 52 | + |
|
| 53 | + * Project must be submit on time, by the deadline. |
|
| 54 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 55 | + * Executed programs must display in a manner similar to provided output |
|
| 56 | + * output formatted, where applicable, must match that of project requirements |
|
| 57 | + * Processing must be correct based on input given and output requested |
|
| 58 | + * Output, if applicable, must be correct based on values input |
|
| 59 | + * Code must be nicely and consistently indented |
|
| 60 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 61 | + * Code must be commented |
|
| 62 | + * Any "to be implemented" comments **MUST** be removed |
|
| 63 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 64 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 65 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 66 | + * Track/version the source code in your private semester repository |
|
| 67 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 68 | + |
|
| 69 | +### SUBMIT TOOL USAGE |
|
| 70 | + |
|
| 71 | +Let's say you have completed work on the project, and are ready to |
|
| 72 | +submit, you would do the following: |
|
| 73 | + |
|
| 74 | +``` |
|
| 75 | +lab46:~/src/SEMESTER/unix/gtf0$ submit unix gtf0 gtf0.sh |
|
| 76 | +``` |
|
| 77 | + |
|
| 78 | +You should get some sort of confirmation indicating successful submission |
|
| 79 | +if all went according to plan. If not, check for typos and or locational |
|
| 80 | +mismatches. |
|
| 81 | + |
|
| 82 | +### RUBRIC |
|
| 83 | + |
|
| 84 | +I'll be evaluating the project based on the following criteria: |
|
| 85 | + |
|
| 86 | +``` |
|
| 87 | +286:gtf0:final tally of results (286/286) |
|
| 88 | +*:gtf0:script operates with no warnings or errors [26/26] |
|
| 89 | +*:gtf0:script produces sc compatible spreadsheet [52/52] |
|
| 90 | +*:gtf0:spreadsheet produce is conformant with gfoX submission criteria [26/26] |
|
| 91 | +*:gtf0:spreadsheet calculations are accurate based on week range [26/26] |
|
| 92 | +*:gtf0:script uses variables, commandline args, if statements, and loops [52/52] |
|
| 93 | +*:gtf0:script uses regex, IO redirection, command expansion [52/52] |
|
| 94 | +*:gtf0:committed script to private semester repo [52/52] |
|
| 95 | +``` |
|
| 96 | + |
|
| 97 | +Additionally: |
|
| 98 | + |
|
| 99 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 100 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 101 | + * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction |
|
| 102 | + * 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 |
haas/fall2026/unix/projects/pbx0.md
| ... | ... | @@ -0,0 +1,257 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: THE PUZZLEBOX (pbx0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Use your observational skills, ability to track and utilize details, |
|
| 8 | +problem solving abilities, and investigative prowess to unravel the |
|
| 9 | +puzzle box, which will attempt to throw obstructions in your path to |
|
| 10 | +deter you from success. |
|
| 11 | + |
|
| 12 | +## PROCESS |
|
| 13 | + |
|
| 14 | +Do note, the productive way to go about this project involves taking the |
|
| 15 | +following steps: |
|
| 16 | + |
|
| 17 | + * starting early |
|
| 18 | + * reading the project page |
|
| 19 | + * asking questions regarding things you do not know, are not clear on, or are confused about |
|
| 20 | + * experimenting and exploring the your files, using tools familiar and new to try and unravel the puzzle. |
|
| 21 | + |
|
| 22 | +If you start too late, and do not ask questions, and do not have enough |
|
| 23 | +time and don't know what is going on, you are not doing the project |
|
| 24 | +correctly. |
|
| 25 | + |
|
| 26 | +## TASK |
|
| 27 | + |
|
| 28 | +You are to unravel the puzzle, getting to the instructions inside. Be |
|
| 29 | +wary of deceptions and obstacles trying to throw you off track. |
|
| 30 | + |
|
| 31 | +To start off, there is a starter puzzle, **ascii.512** that must be |
|
| 32 | +solved and acted upon first before you can get to your actual puzzle. |
|
| 33 | + |
|
| 34 | +Once you work through the starter puzzle, you can proceed to your actual |
|
| 35 | +puzzlebox puzzle. |
|
| 36 | + |
|
| 37 | +You are seeking the creation of two files, that you will submit: |
|
| 38 | + |
|
| 39 | + * **results** - the final instructions correctly unscrambled |
|
| 40 | + * **pbx0steps** - a list of the steps taken to accomplish the core task |
|
| 41 | + |
|
| 42 | +## NO GRABIT |
|
| 43 | + |
|
| 44 | +As part of this activity is to test your ability to navigate around the |
|
| 45 | +filesystem and manipulate files on your own, there is no grabit |
|
| 46 | +configured for this project. |
|
| 47 | + |
|
| 48 | +Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your |
|
| 49 | +project files back into your repository. |
|
| 50 | + |
|
| 51 | +## TOOLBOX |
|
| 52 | + |
|
| 53 | +In addition to tools you may already be familiar with from previous |
|
| 54 | +projects, you may also want to check out: |
|
| 55 | + |
|
| 56 | + * **ar**(**1**) |
|
| 57 | + * **basenc**(**1**) |
|
| 58 | + * **cpio**(**1**) |
|
| 59 | + * **file**(**1**) |
|
| 60 | + * **lzma**(**1**) |
|
| 61 | + * **sort**(**1**) |
|
| 62 | + * **tr**(**1**) |
|
| 63 | + |
|
| 64 | +You are NOT to make use of, as part of your puzzle solution, any steps |
|
| 65 | +that involve interactive tools (such as **nano**), nor utilize **sed**, |
|
| 66 | +**ed**, or **awk** in your solutions. |
|
| 67 | + |
|
| 68 | +## NOTE |
|
| 69 | + |
|
| 70 | +While you may need to install any needed packages on your pi to perform |
|
| 71 | +tasks related to this project, do keep in mind that for the actual |
|
| 72 | +solving of the puzzlebox: |
|
| 73 | + |
|
| 74 | + * you do NOT need to call upon sudo / root access in any way (solutions containing such steps will be considered to not be following the spirit of the project) |
|
| 75 | + * all actionable steps taken are to be done using **non-interactive** tools. There is zero need to make use of an interactive tool like **nano**. Solutions that make central use of interactive tools will be considered to not be following the spirit of the project. |
|
| 76 | + |
|
| 77 | +While you as a user investigating things may end up using various tools |
|
| 78 | +to see what is going on, your resultant steps file is to only be |
|
| 79 | +representative of the core automated/non-interactive task the computer |
|
| 80 | +is performing (with value-added comments giving pertinent clued-in |
|
| 81 | +information as a result of your observations and investigations). |
|
| 82 | + |
|
| 83 | +## BACKGROUND |
|
| 84 | + |
|
| 85 | +The type of a file can be extremely important when determining what |
|
| 86 | +application is used to open it. |
|
| 87 | + |
|
| 88 | +As discussed on a few occasions already, conventional UNIX filesystems do |
|
| 89 | +not have any special treatment for file extensions. It is therefore said |
|
| 90 | +that UNIX ignores them; that means we can use more characters as valid |
|
| 91 | +symbols in filenames. |
|
| 92 | + |
|
| 93 | +On systems that have engrained support for filename extensions (say, a |
|
| 94 | +DOT followed by 3 characters), that actually limits our ability to name |
|
| 95 | +files. |
|
| 96 | + |
|
| 97 | +In UNIX, it is not uncommon to find files named **archive.tar.gz**, and |
|
| 98 | +since UNIX ignores extensions, this is a perfectly legitimate filename... |
|
| 99 | +and it is also quite informative (we are clued in on potential actions |
|
| 100 | +taken on this file, as well as what tools to make use of). |
|
| 101 | + |
|
| 102 | +Most of the time a file is named correctly, for instance a file ending in |
|
| 103 | +**.c** can be assumed to be the source code of a C program, or **.gz** to |
|
| 104 | +be a gzipped file. These are not extensions, they are traditional naming |
|
| 105 | +conventions (just as we tend to call those petrol-powered metal boxes |
|
| 106 | +with 4 rubberized wheels a "car"... we CAN call it something else, but |
|
| 107 | +that may cause bumps in otherwise smooth communications). |
|
| 108 | + |
|
| 109 | +With the **dircolors**(**1**) utility colorizing specific files, it is |
|
| 110 | +further assuming that files which end in **.mpg** are really MPEG files |
|
| 111 | +and colors them accordingly, and the same for **.zip** files, etc. |
|
| 112 | + |
|
| 113 | +In other operating systems, a file's extension determines what |
|
| 114 | +application is used to open the particular file. If a file that ends in |
|
| 115 | +**.mp3** is really a **.png** file, the default MP3 player is going to |
|
| 116 | +have difficulties. |
|
| 117 | + |
|
| 118 | +Sometimes files are not always named properly, either due to a web |
|
| 119 | +browser mangling an extension or for whatever reason. When a file is more |
|
| 120 | +than meets the eye, we must rely on the various tools available to use to |
|
| 121 | +determine what in fact it is. |
|
| 122 | + |
|
| 123 | +## THE FILE UTILITY |
|
| 124 | + |
|
| 125 | +In UNIX there is a nifty little utility called **file** that attempts to |
|
| 126 | +determine the actual type of a file by checking a series of properties. |
|
| 127 | +From the **file**(**1**) man page: |
|
| 128 | + |
|
| 129 | +There are three sets of tests, performed in this order: |
|
| 130 | + |
|
| 131 | + - filesystem tests, |
|
| 132 | + - magic number tests, |
|
| 133 | + - and language tests. |
|
| 134 | + |
|
| 135 | +The first test that succeeds causes the file type to be printed. |
|
| 136 | + |
|
| 137 | +A *filesystem* test checks to see if the file is non-ordinary (such as a |
|
| 138 | +socket, symbolic link, or other special file). |
|
| 139 | + |
|
| 140 | +The *magic number* test is a check of files conforming to existing fixed |
|
| 141 | +formats, typically by examining the file at the binary level. If using a |
|
| 142 | +hex editor, you will find that **.gz** files should always start with the |
|
| 143 | +same sequence of hexadecimal values. |
|
| 144 | + |
|
| 145 | +Finally, if the file is determined to be a simple ASCII file, it will |
|
| 146 | +attempt to analyze whether or not it conforms to some language (ie C |
|
| 147 | +source code vs. an HTML document). |
|
| 148 | + |
|
| 149 | +Note that **file** is not always perfect, but for most cases will get the |
|
| 150 | +job done. Try checking files in your home directory or elsewhere on the |
|
| 151 | +system and see the results. Should file not be able to give you a clear |
|
| 152 | +answer, you must still result to your other skills and mental faculties-- |
|
| 153 | +test and debug the situation. |
|
| 154 | + |
|
| 155 | +Refer to the **file**(**1**) manual page or your references for more |
|
| 156 | +information. |
|
| 157 | + |
|
| 158 | +## PROJECT |
|
| 159 | + |
|
| 160 | +For this project, files are located in the **pbx0/** subdirectory of the |
|
| 161 | +**UNIX Public Directory**. |
|
| 162 | + |
|
| 163 | +There is a directory by the name of your user, which contains a file. |
|
| 164 | +Please copy this into some custom project folder in your home directory. |
|
| 165 | + |
|
| 166 | +Using your debugging, observation, and analytical skills, unravel the |
|
| 167 | +puzzle until you have an ordered, plain text, english readable file |
|
| 168 | +(called **results**) with directions on how to submit the project. |
|
| 169 | + |
|
| 170 | +In many puzzles, one's visual comprehension of the scenario plays a vital |
|
| 171 | +role. Where something doesn't necessarily meet the eye, or is not |
|
| 172 | +behaving as you would expect- just try reading any messages or output. |
|
| 173 | +Sometimes the clues are right under your nose. |
|
| 174 | + |
|
| 175 | +As is the case many investigations, just observing how things behave can |
|
| 176 | +lead to recognition of an object's true state, or the recognition of a |
|
| 177 | +pattern, which can be used to solve the task at hand. |
|
| 178 | + |
|
| 179 | +## VERIFICATION |
|
| 180 | + |
|
| 181 | +The **results** file, when correctly unscrambled and assembled, can be |
|
| 182 | +verified by generating its **md5sum** hash. |
|
| 183 | + |
|
| 184 | +This hash should match the hash stored inside the **MANIFEST** file |
|
| 185 | +located in the project directory (in the public directory). |
|
| 186 | + |
|
| 187 | +### FILECHK |
|
| 188 | + |
|
| 189 | +You can also use the **filechk** tool to verify the accuracy of your |
|
| 190 | +results: |
|
| 191 | + |
|
| 192 | +``` |
|
| 193 | +lab46:~/src/SEMESTER/unix/pbx0$ filechk unix pbx0 |
|
| 194 | +``` |
|
| 195 | + |
|
| 196 | +## SUBMISSION |
|
| 197 | + |
|
| 198 | +In addition to the files produced during the completion of this project, |
|
| 199 | +I would also like for you to create a detailed step-by-step text file |
|
| 200 | +called **pbx0steps** which includes the valid command-lines that will |
|
| 201 | +document for me the steps you took from project commencement through |
|
| 202 | +completion. You will submit this file at the end in accordance with the |
|
| 203 | +instructions. |
|
| 204 | + |
|
| 205 | +To successfully complete this project, you must follow the directions |
|
| 206 | +located in a readable file at the conclusion of this project. Until you |
|
| 207 | +encounter it, you are not yet finished (hint). |
|
| 208 | + |
|
| 209 | +You should get some sort of confirmation indicating successful submission |
|
| 210 | +(actually, two) if all went according to plan. If not, check for typos |
|
| 211 | +and or locational mismatches. |
|
| 212 | + |
|
| 213 | +### SUBMIT TOOL USAGE |
|
| 214 | + |
|
| 215 | +Let's say you have completed work on the project, and are ready to |
|
| 216 | +submit, you would do the following: |
|
| 217 | + |
|
| 218 | +``` |
|
| 219 | +lab46:~/src/SEMESTER/unix/pbx0$ submit unix pbx0 file1 file2 file3 ... fileN |
|
| 220 | +``` |
|
| 221 | + |
|
| 222 | +A less abstract instantiation of the above (to help you transition): |
|
| 223 | + |
|
| 224 | +``` |
|
| 225 | +lab46:~/src/SEMESTER/unix/pbx0$ submit unix pbx0 results pbx0steps |
|
| 226 | +Submitting unix project "pbx0": |
|
| 227 | + -> results(OK) |
|
| 228 | + -> pbx0steps(OK) |
|
| 229 | + |
|
| 230 | +SUCCESSFULLY SUBMITTED |
|
| 231 | +``` |
|
| 232 | + |
|
| 233 | +You should get some sort of confirmation indicating successful submission |
|
| 234 | +if all went according to plan. If not, check for typos and or locational |
|
| 235 | +mismatches. |
|
| 236 | + |
|
| 237 | +I'll be looking for the following: |
|
| 238 | + |
|
| 239 | +### RUBRIC |
|
| 240 | + |
|
| 241 | +``` |
|
| 242 | +104:pbx0:final tally of results (104/104) |
|
| 243 | +*:pbx0:submitted results file via submit tool [13/13] |
|
| 244 | +*:pbx0:submitted pbx0steps file via submit tool [13/13] |
|
| 245 | +*:pbx0:results md5sum matches project MANIFEST [13/13] |
|
| 246 | +*:pbx0:results is correctly unscrambled and assembled [13/13] |
|
| 247 | +*:pbx0:pbx0steps contains valid set of instructions [13/13] |
|
| 248 | +*:pbx0:pbx0steps any commentary after hash mark [13/13] |
|
| 249 | +*:pbx0:emailed results via instructions [13/13] |
|
| 250 | +*:pbx0:matching subject line as per instructions [13/13] |
|
| 251 | +``` |
|
| 252 | + |
|
| 253 | +Additionally: |
|
| 254 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 255 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 256 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 257 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/unix/projects/pbx1.md
| ... | ... | @@ -0,0 +1,209 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: THE PUZZLEBOX (pbx1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Continue to cultivate your skills, problem solving abilities, and ability |
|
| 8 | +to explore and figure out new tools. |
|
| 9 | + |
|
| 10 | +## PROCESS |
|
| 11 | + |
|
| 12 | +Do note, the productive way to go about this project involves taking the |
|
| 13 | +following steps: |
|
| 14 | + |
|
| 15 | + * starting early |
|
| 16 | + * reading the project page |
|
| 17 | + * asking questions regarding things you do not know, are not clear on, or are confused about |
|
| 18 | + * experimenting and exploring the your files, using tools familiar and new to try and unravel the puzzle. |
|
| 19 | + |
|
| 20 | +If you start too late, and do not ask questions, and do not have enough |
|
| 21 | +time and don't know what is going on, you are not doing the project |
|
| 22 | +correctly. |
|
| 23 | + |
|
| 24 | +## TASK |
|
| 25 | + |
|
| 26 | +You are to unravel the puzzle, getting to the instructions inside. Be |
|
| 27 | +wary of deceptions and obstacles trying to throw you off track. |
|
| 28 | + |
|
| 29 | +You are seeking the creation of two files, that you will submit: |
|
| 30 | + |
|
| 31 | + * **pbx1.results** - the final instructions correctly unscrambled |
|
| 32 | + * **pbx1steps** - a list of the steps taken to accomplish the core task |
|
| 33 | + |
|
| 34 | +## NO GRABIT |
|
| 35 | + |
|
| 36 | +As part of this activity is to test your ability to navigate around the |
|
| 37 | +filesystem and manipulate files on your own, there is no grabit |
|
| 38 | +configured for this project. |
|
| 39 | + |
|
| 40 | +Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your |
|
| 41 | +project files back into your repository. |
|
| 42 | + |
|
| 43 | +## OBTAIN THE FILES |
|
| 44 | + |
|
| 45 | +This week's project is located in the **pbx1/** sub-directory of the UNIX |
|
| 46 | +Public Directory, under a directory by the name of your username, there |
|
| 47 | +should be 2 files. One named **README**, and another. |
|
| 48 | + |
|
| 49 | +Make a copy into your home directory somewhere and set to work. |
|
| 50 | + |
|
| 51 | +**NOTE:** Hopefully it has been standard practice to locate project files |
|
| 52 | +in their own unique subdirectory, such as under **src/SEMESTER/unix/**, |
|
| 53 | +where you can then add/commit/push the results to your repository (you |
|
| 54 | +ARE regularly putting stuff in your repository, aren't you?) |
|
| 55 | + |
|
| 56 | +## COMMENTARY |
|
| 57 | + |
|
| 58 | +The first puzzlebox was in many ways a test of your observational skills. |
|
| 59 | +To many, the frustrations emerged from what was being taken for granted. |
|
| 60 | +But once you took proper notice, and could apply the appropriate skills, |
|
| 61 | +its secrets could be obtained. |
|
| 62 | + |
|
| 63 | +This second puzzlebox will test both your observation skills (in a |
|
| 64 | +slightly different way) and reasoning skills in an abstract manner. Along |
|
| 65 | +with that, your scripting skills are being put to the test as well: your |
|
| 66 | +submission will more heavily rely upon a fully functional steps file that |
|
| 67 | +will entirely automate the process. If you are observant, the information |
|
| 68 | +you need is presented early on, but is a few layers of abstraction out of |
|
| 69 | +reach. Patience and perseverance will be key to victory. |
|
| 70 | + |
|
| 71 | +If you start too late, and do not ask questions, and do not have enough |
|
| 72 | +time and don't know what is going on, you are not doing the project |
|
| 73 | +correctly. |
|
| 74 | + |
|
| 75 | +## TOOLBOX |
|
| 76 | + |
|
| 77 | +In addition to tools you may already be familiar with from previous |
|
| 78 | +projects, you may also want to check out: |
|
| 79 | + |
|
| 80 | + * **ar**(**1**) |
|
| 81 | + * **basenc**(**1**) |
|
| 82 | + * **cpio**(**1**) |
|
| 83 | + * **file**(**1**) |
|
| 84 | + * **lzma**(**1**) |
|
| 85 | + * **cat**(1) |
|
| 86 | + * **cut**(1) |
|
| 87 | + * **grep**(1) |
|
| 88 | + * **head**(1) |
|
| 89 | + * **paste**(1) |
|
| 90 | + * **sort**(1) |
|
| 91 | + * **tail**(1) |
|
| 92 | + * **tr**(1) |
|
| 93 | + * **uudecode**(1) |
|
| 94 | + * **uniq**(1) |
|
| 95 | + |
|
| 96 | +You are NOT to make use of, as part of your puzzle solution, any steps |
|
| 97 | +that involve interactive tools (such as **nano**), nor utilize **sed**, |
|
| 98 | +**ed**, or **awk** in your solutions. |
|
| 99 | + |
|
| 100 | +## NOTE |
|
| 101 | + |
|
| 102 | +While you may need to install any needed packages on your pi to perform |
|
| 103 | +tasks related to this project, do keep in mind that for the actual |
|
| 104 | +solving of the puzzlebox: |
|
| 105 | + |
|
| 106 | + * you do NOT need to call upon sudo / root access in any way (solutions containing such steps will be considered to not be following the spirit of the project) |
|
| 107 | + * all actionable steps taken are to be done using **non-interactive** tools. There is zero need to make use of an interactive tool like **nano**. Solutions that make central use of interactive tools will be considered to not be following the spirit of the project. |
|
| 108 | + |
|
| 109 | +While you as a user investigating things may end up using various tools |
|
| 110 | +to see what is going on, your resultant steps file is to only be |
|
| 111 | +representative of the core automated/non-interactive task the computer |
|
| 112 | +is performing (with value-added comments giving pertinent clued-in |
|
| 113 | +information as a result of your observations and investigations). |
|
| 114 | + |
|
| 115 | +## PROJECT |
|
| 116 | + |
|
| 117 | +For this project, files are located in the **pbx1/** subdirectory of the |
|
| 118 | +**UNIX Public Directory**. |
|
| 119 | + |
|
| 120 | +There is a directory by the name of your user, which contains a file. |
|
| 121 | +Please copy this into some custom project folder in your home directory. |
|
| 122 | + |
|
| 123 | +In many puzzles, one's visual comprehension of the scenario plays a vital |
|
| 124 | +role. Where something doesn't necessarily meet the eye, or is not |
|
| 125 | +behaving as you would expect- just try reading any messages or output. |
|
| 126 | +Sometimes the clues are right under your nose. |
|
| 127 | + |
|
| 128 | +As is the case many investigations, just observing how things behave can |
|
| 129 | +lead to recognition of an object's true state, or the recognition of a |
|
| 130 | +pattern, which can be used to solve the task at hand. |
|
| 131 | + |
|
| 132 | +## VERIFICATION |
|
| 133 | + |
|
| 134 | +The **pbx1.results** file, when correctly unscrambled and assembled, can |
|
| 135 | +be verified by generating its **md5sum** hash. |
|
| 136 | + |
|
| 137 | +This hash should match the hash stored inside the **MANIFEST** file |
|
| 138 | +located in the project directory (in the public directory). |
|
| 139 | + |
|
| 140 | +### FILECHK |
|
| 141 | + |
|
| 142 | +You can also use the **filechk** tool to verify the accuracy of your |
|
| 143 | +results: |
|
| 144 | + |
|
| 145 | +``` |
|
| 146 | +lab46:~/src/SEMESTER/unix/pbx1$ filechk unix pbx1 |
|
| 147 | +``` |
|
| 148 | + |
|
| 149 | +## SUBMISSION |
|
| 150 | + |
|
| 151 | +In addition to the files produced during the completion of this project, |
|
| 152 | +I would also like for you to create a detailed step-by-step text file |
|
| 153 | +called **pbx1steps** which includes the valid command-lines that will |
|
| 154 | +document for me the steps you took from project commencement through |
|
| 155 | +completion. You will submit this file at the end in accordance with the |
|
| 156 | +instructions. |
|
| 157 | + |
|
| 158 | +You should get some sort of confirmation indicating successful submission |
|
| 159 | +(actually, two) if all went according to plan. If not, check for typos |
|
| 160 | +and or locational mismatches. |
|
| 161 | + |
|
| 162 | +### SUBMIT TOOL USAGE |
|
| 163 | + |
|
| 164 | +Let's say you have completed work on the project, and are ready to |
|
| 165 | +submit, you would do the following: |
|
| 166 | + |
|
| 167 | +``` |
|
| 168 | +lab46:~/src/SEMESTER/unix/pbx1$ submit unix pbx1 file1 file2 file3 ... fileN |
|
| 169 | +``` |
|
| 170 | + |
|
| 171 | +A less abstract instantiation of the above (to help you transition): |
|
| 172 | + |
|
| 173 | +``` |
|
| 174 | +lab46:~/src/SEMESTER/unix/pbx1$ submit unix pbx1 pbx1.results pbx1steps |
|
| 175 | +Submitting unix project "pbx1": |
|
| 176 | + -> pbx1.results(OK) |
|
| 177 | + -> pbx1steps(OK) |
|
| 178 | + |
|
| 179 | +SUCCESSFULLY SUBMITTED |
|
| 180 | +``` |
|
| 181 | + |
|
| 182 | +You should get some sort of confirmation indicating successful submission |
|
| 183 | +if all went according to plan. If not, check for typos and or locational |
|
| 184 | +mismatches. |
|
| 185 | + |
|
| 186 | +I'll be looking for the following: |
|
| 187 | + |
|
| 188 | +### RUBRIC |
|
| 189 | + |
|
| 190 | +``` |
|
| 191 | +130:pbx1:final tally of results (130/130) |
|
| 192 | +*:pbx1:submitted pbx1.results file via submit tool [13/13] |
|
| 193 | +*:pbx1:submitted pbx1steps file via submit tool [13/13] |
|
| 194 | +*:pbx1:both files pushed to private semester repository [13/13] |
|
| 195 | +*:pbx1:pbx1.results is correctly unscrambled and assembled [13/13] |
|
| 196 | +*:pbx1:pbx1.results md5sum matches project MANIFEST [13/13] |
|
| 197 | +*:pbx1:pbx1steps has valid list of non-interactive instructions [13/13] |
|
| 198 | +*:pbx1:pbx1steps uses shell features like wildcards, IO redir [13/13] |
|
| 199 | +*:pbx1:pbx1steps contains comments explaining process [13/13] |
|
| 200 | +*:pbx1:pbx1steps automates the project when executed [13/13] |
|
| 201 | +*:pbx1:pbx1steps when executed outputs nothing [13/13] |
|
| 202 | +``` |
|
| 203 | + |
|
| 204 | +Additionally: |
|
| 205 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 206 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 207 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 208 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
|
| 209 | + |
haas/fall2026/unix/projects/pbx2.md
| ... | ... | @@ -0,0 +1,207 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: THE PUZZLEBOX (pbx2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Continue to cultivate your skills, problem solving abilities, and ability |
|
| 8 | +to explore and figure out new tools. |
|
| 9 | + |
|
| 10 | +## PROCESS |
|
| 11 | + |
|
| 12 | +Do note, the productive way to go about this project involves taking the |
|
| 13 | +following steps: |
|
| 14 | + |
|
| 15 | + * starting early |
|
| 16 | + * reading the project page |
|
| 17 | + * asking questions regarding things you do not know, are not clear on, or are confused about |
|
| 18 | + * experimenting and exploring the your files, using tools familiar and new to try and unravel the puzzle. |
|
| 19 | + |
|
| 20 | +If you start too late, and do not ask questions, and do not have enough |
|
| 21 | +time and don't know what is going on, you are not doing the project |
|
| 22 | +correctly. |
|
| 23 | + |
|
| 24 | +## TASK |
|
| 25 | + |
|
| 26 | +You are to unravel the puzzle, getting to the instructions inside. Be |
|
| 27 | +wary of deceptions and obstacles trying to throw you off track. |
|
| 28 | + |
|
| 29 | +You are seeking the creation of two files, that you will submit: |
|
| 30 | + |
|
| 31 | + * **pbx2.results** - the final instructions correctly unscrambled |
|
| 32 | + * **pbx2steps** - a list of the steps taken to accomplish the core task |
|
| 33 | + |
|
| 34 | +## NO GRABIT |
|
| 35 | + |
|
| 36 | +As part of this activity is to test your ability to navigate around the |
|
| 37 | +filesystem and manipulate files on your own, there is no grabit |
|
| 38 | +configured for this project. |
|
| 39 | + |
|
| 40 | +Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your |
|
| 41 | +project files back into your repository. |
|
| 42 | + |
|
| 43 | +## OBTAIN THE FILES |
|
| 44 | + |
|
| 45 | +This week's project is located in the **pbx2/** sub-directory of the UNIX |
|
| 46 | +Public Directory, under a directory by the name of your username, there |
|
| 47 | +should be a 2 files, one called `EXAMPLE` and another. |
|
| 48 | + |
|
| 49 | +`EXAMPLE` is an unobfuscated example of what your final result from |
|
| 50 | +unravelling the puzzle should look like (not *exactly* like this, but in |
|
| 51 | +this form). Study it, its patterns may help you during the solving of |
|
| 52 | +this puzzle box. |
|
| 53 | + |
|
| 54 | +Make a copy into your home directory somewhere and set to work. |
|
| 55 | + |
|
| 56 | +**NOTE:** Hopefully it has been standard practice to locate project files |
|
| 57 | +in their own unique subdirectory, such as under **src/SEMESTER/unix/**, |
|
| 58 | +where you can then add/commit/push the results to your repository (you |
|
| 59 | +ARE regularly putting stuff in your repository, aren't you?) |
|
| 60 | + |
|
| 61 | +## COMMENTARY |
|
| 62 | + |
|
| 63 | +The first puzzlebox was in many ways a test of your observational skills. |
|
| 64 | +To many, the frustrations emerged from what was being taken for granted. |
|
| 65 | +But once you took proper notice, and could apply the appropriate skills, |
|
| 66 | +its secrets could be obtained. |
|
| 67 | + |
|
| 68 | +The second puzzlebox will test both your observation skills (in a |
|
| 69 | +slightly different way) and reasoning skills in an abstract manner. Along |
|
| 70 | +with that, your scripting skills are being put to the test as well: your |
|
| 71 | +submission will more heavily rely upon a fully functional steps file that |
|
| 72 | +will entirely automate the process. If you are observant, the information |
|
| 73 | +you need is presented early on, but is a few layers of abstraction out of |
|
| 74 | +reach. Patience and perseverance will be key to victory. |
|
| 75 | + |
|
| 76 | +This third one continues to put your skills to the test with new and |
|
| 77 | +exciting obfuscations. |
|
| 78 | + |
|
| 79 | +If you start too late, and do not ask questions, and do not have enough |
|
| 80 | +time and don't know what is going on, you are not doing the project |
|
| 81 | +correctly. |
|
| 82 | + |
|
| 83 | +You are NOT to make use of, as part of your puzzle solution, any steps |
|
| 84 | +that involve interactive tools (such as **nano** or **vi/vim**), nor |
|
| 85 | +utilize **sed**, **ed**, or **awk** in your solutions. |
|
| 86 | + |
|
| 87 | +## NOTE |
|
| 88 | + |
|
| 89 | +While you may need to install any needed packages on your pi to perform |
|
| 90 | +tasks related to this project, do keep in mind that for the actual |
|
| 91 | +solving of the puzzlebox: |
|
| 92 | + |
|
| 93 | +You do NOT need to call upon sudo / root access in any way (solutions |
|
| 94 | +containing such steps will be considered to not be following the spirit |
|
| 95 | +of the project) |
|
| 96 | + |
|
| 97 | +Also: all actionable steps taken are to be done using **non-interactive** |
|
| 98 | +tools. There is zero need to make use of an interactive tool like |
|
| 99 | +**nano**. Solutions that make central use of interactive tools will be |
|
| 100 | +considered to not be following the spirit of the project. |
|
| 101 | + |
|
| 102 | +While you as a user investigating things may end up using various tools |
|
| 103 | +to see what is going on, your resultant steps file is to only be |
|
| 104 | +representative of the core automated/non-interactive task the computer |
|
| 105 | +is performing (with value-added comments giving pertinent clued-in |
|
| 106 | +information as a result of your observations and investigations). |
|
| 107 | + |
|
| 108 | +## PROJECT |
|
| 109 | + |
|
| 110 | +For this project, files are located in the **pbx2/** subdirectory of the |
|
| 111 | +**UNIX Public Directory**. |
|
| 112 | + |
|
| 113 | +There is a directory by the name of your user, which contains a file. |
|
| 114 | +Please copy this into some custom project folder in your home directory. |
|
| 115 | + |
|
| 116 | +In many puzzles, one's visual comprehension of the scenario plays a vital |
|
| 117 | +role. Where something doesn't necessarily meet the eye, or is not |
|
| 118 | +behaving as you would expect- just try reading any messages or output. |
|
| 119 | +Sometimes the clues are right under your nose. |
|
| 120 | + |
|
| 121 | +As is the case many investigations, just observing how things behave can |
|
| 122 | +lead to recognition of an object's true state, or the recognition of a |
|
| 123 | +pattern, which can be used to solve the task at hand. |
|
| 124 | + |
|
| 125 | +## VERIFICATION |
|
| 126 | + |
|
| 127 | +The **pbx2.results** file, when correctly unscrambled and assembled, can |
|
| 128 | +be verified by generating its **sha384sum** hash. |
|
| 129 | + |
|
| 130 | +This hash should match the hash stored inside the **MANIFEST** file |
|
| 131 | +located in the project directory (in the public directory). |
|
| 132 | + |
|
| 133 | +### FILECHK |
|
| 134 | + |
|
| 135 | +You can also use the **filechk** tool to verify the accuracy of your |
|
| 136 | +results: |
|
| 137 | + |
|
| 138 | +``` |
|
| 139 | +lab46:~/src/SEMESTER/unix/pbx2$ filechk unix pbx2 |
|
| 140 | +``` |
|
| 141 | + |
|
| 142 | +## SUBMISSION |
|
| 143 | + |
|
| 144 | +In addition to the files produced during the completion of this project, |
|
| 145 | +I would also like for you to create a detailed step-by-step text file |
|
| 146 | +called **pbx2steps** which includes the valid command-lines that will |
|
| 147 | +document for me the steps you took from project commencement through |
|
| 148 | +completion. You will submit this file at the end in accordance with the |
|
| 149 | +instructions. |
|
| 150 | + |
|
| 151 | +To successfully complete this project, you must follow the directions |
|
| 152 | +located in a readable file at the conclusion of this project. Until you |
|
| 153 | +encounter it, you are not yet finished (hint). |
|
| 154 | + |
|
| 155 | +You should get some sort of confirmation indicating successful submission |
|
| 156 | +(actually, two) if all went according to plan. If not, check for typos |
|
| 157 | +and or locational mismatches. |
|
| 158 | + |
|
| 159 | +### SUBMIT TOOL USAGE |
|
| 160 | + |
|
| 161 | +Let's say you have completed work on the project, and are ready to |
|
| 162 | +submit, you would do the following: |
|
| 163 | + |
|
| 164 | +``` |
|
| 165 | +lab46:~/src/SEMESTER/unix/pbx2$ submit unix pbx2 file1 file2 file3 ... fileN |
|
| 166 | +``` |
|
| 167 | + |
|
| 168 | +A less abstract instantiation of the above (to help you transition): |
|
| 169 | + |
|
| 170 | +``` |
|
| 171 | +lab46:~/src/SEMESTER/unix/pbx2$ submit unix pbx2 pbx2.results pbx1steps |
|
| 172 | +Submitting unix project "pbx2": |
|
| 173 | + -> pbx2.results(OK) |
|
| 174 | + -> pbx2steps(OK) |
|
| 175 | + |
|
| 176 | +SUCCESSFULLY SUBMITTED |
|
| 177 | +``` |
|
| 178 | + |
|
| 179 | +You should get some sort of confirmation indicating successful submission |
|
| 180 | +if all went according to plan. If not, check for typos and or locational |
|
| 181 | +mismatches. |
|
| 182 | + |
|
| 183 | +I'll be looking for the following: |
|
| 184 | + |
|
| 185 | +### RUBRIC |
|
| 186 | + |
|
| 187 | +``` |
|
| 188 | +156:pbx2:final tally of results (156/156) |
|
| 189 | +*:pbx2:post screenshot of results to DISCORD channel [13/13] |
|
| 190 | +*:pbx2:submitted pbx2.results file via submit tool [13/13] |
|
| 191 | +*:pbx2:submitted pbx2steps file via submit tool [13/13] |
|
| 192 | +*:pbx2:both files pushed to private semester repository [13/13] |
|
| 193 | +*:pbx2:pbx2.results is correctly unscrambled and assembled [13/13] |
|
| 194 | +*:pbx2:pbx2.results md5sum matches project MANIFEST [13/13] |
|
| 195 | +*:pbx2:pbx2steps has valid list of non-interactive instructions [13/13] |
|
| 196 | +*:pbx2:pbx2steps uses shell features like wildcards, IO redir [13/13] |
|
| 197 | +*:pbx2:pbx2steps uses shell features like command expansions [13/13] |
|
| 198 | +*:pbx2:pbx2steps contains comments explaining process [13/13] |
|
| 199 | +*:pbx2:pbx2steps automates the project when executed [13/13] |
|
| 200 | +*:pbx2:pbx2steps when executed outputs nothing [13/13] |
|
| 201 | +``` |
|
| 202 | + |
|
| 203 | +Additionally: |
|
| 204 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 205 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 206 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 207 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/unix/projects/pwn0.md
| ... | ... | @@ -0,0 +1,939 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: PROCESSING WARRANTED NUMBERS (pwn0) |
|
| 4 | + |
|
| 5 | +## TOOLBOX |
|
| 6 | + |
|
| 7 | +In addition to the tools you're already familiar with, it is recommended |
|
| 8 | +you check out the following tools for possible application in this |
|
| 9 | +project (you may not need to use them in your solution, but they |
|
| 10 | +definitely offer up functionality that some solutions can make use of): |
|
| 11 | + |
|
| 12 | + * **bc(1)** |
|
| 13 | + * **comm(1)** |
|
| 14 | + * **diff(1)** |
|
| 15 | + * **grep(1)** |
|
| 16 | + * **join(1)** |
|
| 17 | + * **printf(1)** |
|
| 18 | + * **seq(1)** |
|
| 19 | + * **sort(1)** |
|
| 20 | + * **uniq(1)** |
|
| 21 | + |
|
| 22 | +## REFERENCE |
|
| 23 | + |
|
| 24 | +For additional information on the **printf(1)** tool recommended for use |
|
| 25 | +in this project, please check out this paper: |
|
| 26 | + |
|
| 27 | + * https://lab46.g7n.org/downloads/printf.pdf |
|
| 28 | + |
|
| 29 | +NOTE that while it focuses on the C and Perl variants of printf, the |
|
| 30 | +conceptual underpinnings are the same, and many of the examples are |
|
| 31 | +likely portable to the UNIX variant of the tool. |
|
| 32 | + |
|
| 33 | +## OBJECTIVE |
|
| 34 | + |
|
| 35 | +To create a script that can, with or without information provided by the |
|
| 36 | +user, display useful reference data in various number bases. |
|
| 37 | + |
|
| 38 | +## BACKGROUND |
|
| 39 | + |
|
| 40 | +We've encountered many things in our UNIX journey so far, and have been |
|
| 41 | +readily building upon past experiences as we achieve newer and better |
|
| 42 | +successes. Of particular focus, we've been looking at shell scripting, |
|
| 43 | +and that will be the primary focus of this week's project. |
|
| 44 | + |
|
| 45 | +There are collections of information quite useful to anyone journeying |
|
| 46 | +in a discipline, and computing is no different: We often encounter |
|
| 47 | +information represented in certain units more than others, or various |
|
| 48 | +quantities, or even particular number bases. |
|
| 49 | + |
|
| 50 | +### BINARY/OCTAL/HEX |
|
| 51 | + |
|
| 52 | +One particular collection of information involves that of binary, octal, |
|
| 53 | +decimal (in signed and unsigned capacities) and hexadecimal numbers. We |
|
| 54 | +may encounter a tool that gives us information in octal and we need to |
|
| 55 | +feed it into another tool as binary or decimal; these sorts of |
|
| 56 | +transactions are common and crop up time and time again. |
|
| 57 | + |
|
| 58 | +Having a strong handle on this information is vital for on-going success |
|
| 59 | +in the computing field. |
|
| 60 | + |
|
| 61 | +As such, it is important to have close at hand the knowledge of the |
|
| 62 | +following number bases: |
|
| 63 | + |
|
| 64 | + * base 2 (binary) |
|
| 65 | + * base 8 (octal) |
|
| 66 | + * base 10 (decimal, specifically signed and unsigned quantities) |
|
| 67 | + * base 16 (hexadecimal) |
|
| 68 | + |
|
| 69 | +While we don't need to have hundreds of values memorized, it IS a good |
|
| 70 | +idea to have a rather quick recollection of enough values that can be |
|
| 71 | +used for debugging purposes. The first 16 values of each of these is such |
|
| 72 | +a preferred range. Not only does it give us a range of information, but |
|
| 73 | +for the powers-of-two bases, can actually fit in and be propagated quite |
|
| 74 | +nicely with little added effort. |
|
| 75 | + |
|
| 76 | +## PROCESS |
|
| 77 | + |
|
| 78 | +It is your task to write a script that, when run without any arguments, |
|
| 79 | +produces the following table of information (and displayed/formatted in |
|
| 80 | +this exact manner): |
|
| 81 | + |
|
| 82 | +``` |
|
| 83 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh |
|
| 84 | + base 2 | base 8 | base10 | base16 | |
|
| 85 | +----------+----------+----------+----------+ |
|
| 86 | + 0 | 0 | 0 | 0 | |
|
| 87 | + 1 | 1 | 1 | 1 | |
|
| 88 | + 10 | 2 | 2 | 2 | |
|
| 89 | + 11 | 3 | 3 | 3 | |
|
| 90 | + 100 | 4 | 4 | 4 | |
|
| 91 | + 101 | 5 | 5 | 5 | |
|
| 92 | + 110 | 6 | 6 | 6 | |
|
| 93 | + 111 | 7 | 7 | 7 | |
|
| 94 | + 1000 | 10 | 8 | 8 | |
|
| 95 | + 1001 | 11 | 9 | 9 | |
|
| 96 | + 1010 | 12 | 10 | A | |
|
| 97 | + 1011 | 13 | 11 | B | |
|
| 98 | + 1100 | 14 | 12 | C | |
|
| 99 | + 1101 | 15 | 13 | D | |
|
| 100 | + 1110 | 16 | 14 | E | |
|
| 101 | + 1111 | 17 | 15 | F | |
|
| 102 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 103 | +``` |
|
| 104 | + |
|
| 105 | +Your script should also take the following optional arguments (in this |
|
| 106 | +order): |
|
| 107 | + |
|
| 108 | + * **$1**- starting value (some value greater than or equal to 0, and less than 256) |
|
| 109 | + * **$2**- ending value (some value greater than or equal to 0, and less than 256) |
|
| 110 | + |
|
| 111 | +Numerical arguments are to be given in decimal. |
|
| 112 | + |
|
| 113 | +Additional arguments your script should support: |
|
| 114 | + |
|
| 115 | + * **by#** - iterate through values by # (default: 1) |
|
| 116 | + * **with#** - include base # in the list of bases to display |
|
| 117 | + * **sans#** - remove base # in the list of bases to display |
|
| 118 | + * **help** - display script usage and exit |
|
| 119 | + |
|
| 120 | +With any of these arguments validly provided, they should adjust the |
|
| 121 | +script's processing and output accordingly. |
|
| 122 | + |
|
| 123 | +Some additional constraints/assumptions you can make: |
|
| 124 | + |
|
| 125 | + * the minimum lower limit your script should process for is **0**. If an input goes negative, cap it to 0. |
|
| 126 | + * the maximum upper limit you can implement for is **255** (base 10). If an input goes in excess of this, cap it to 255. |
|
| 127 | + |
|
| 128 | +### ONLY SPECIFYING STARTING VALUE |
|
| 129 | + |
|
| 130 | +In the event only the starting value is specified, assume a count of 16 |
|
| 131 | +(so display 16 values, starting at the starting value). |
|
| 132 | + |
|
| 133 | +For example: |
|
| 134 | + |
|
| 135 | +``` |
|
| 136 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 12 |
|
| 137 | + base 2 | base 8 | base10 | base16 | |
|
| 138 | +----------+----------+----------+----------+ |
|
| 139 | + 1100 | 14 | 12 | C | |
|
| 140 | + 1101 | 15 | 13 | D | |
|
| 141 | + 1110 | 16 | 14 | E | |
|
| 142 | + 1111 | 17 | 15 | F | |
|
| 143 | + 10000 | 20 | 16 | 10 | |
|
| 144 | + 10001 | 21 | 17 | 11 | |
|
| 145 | + 10010 | 22 | 18 | 12 | |
|
| 146 | + 10011 | 23 | 19 | 13 | |
|
| 147 | + 10100 | 24 | 20 | 14 | |
|
| 148 | + 10101 | 25 | 21 | 15 | |
|
| 149 | + 10110 | 26 | 22 | 16 | |
|
| 150 | + 10111 | 27 | 23 | 17 | |
|
| 151 | + 11000 | 30 | 24 | 18 | |
|
| 152 | + 11001 | 31 | 25 | 19 | |
|
| 153 | + 11010 | 32 | 26 | 1A | |
|
| 154 | + 11011 | 33 | 27 | 1B | |
|
| 155 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 156 | +``` |
|
| 157 | + |
|
| 158 | +### SPECIFYING STARTING AND ENDING VALUE |
|
| 159 | + |
|
| 160 | +We can adjust the range displayed by specifying an ending value as well: |
|
| 161 | + |
|
| 162 | +``` |
|
| 163 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 37 42 |
|
| 164 | + base 2 | base 8 | base10 | base16 | |
|
| 165 | +----------+----------+----------+----------+ |
|
| 166 | + 100101 | 45 | 37 | 25 | |
|
| 167 | + 100110 | 46 | 38 | 26 | |
|
| 168 | + 100111 | 47 | 39 | 27 | |
|
| 169 | + 101000 | 50 | 40 | 28 | |
|
| 170 | + 101001 | 51 | 41 | 29 | |
|
| 171 | + 101010 | 52 | 42 | 2A | |
|
| 172 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 173 | +``` |
|
| 174 | + |
|
| 175 | +With a specified starting/ending value pair, we can display as little as |
|
| 176 | +1 value and (theoretically) as many as we want. |
|
| 177 | + |
|
| 178 | +### GOING BACKWARDS |
|
| 179 | + |
|
| 180 | +It shouldn't matter the relationship of starting and ending values. In |
|
| 181 | +fact, if the starting value is HIGHER than the ending value, the count |
|
| 182 | +should go backwards: |
|
| 183 | + |
|
| 184 | +``` |
|
| 185 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 73 59 |
|
| 186 | + base 2 | base 8 | base10 | base16 | |
|
| 187 | +----------+----------+----------+----------+ |
|
| 188 | + 1001001 | 111 | 73 | 49 | |
|
| 189 | + 1001000 | 110 | 72 | 48 | |
|
| 190 | + 1000111 | 107 | 71 | 47 | |
|
| 191 | + 1000110 | 106 | 70 | 46 | |
|
| 192 | + 1000101 | 105 | 69 | 45 | |
|
| 193 | + 1000100 | 104 | 68 | 44 | |
|
| 194 | + 1000011 | 103 | 67 | 43 | |
|
| 195 | + 1000010 | 102 | 66 | 42 | |
|
| 196 | + 1000001 | 101 | 65 | 41 | |
|
| 197 | + 1000000 | 100 | 64 | 40 | |
|
| 198 | + 111111 | 77 | 63 | 3F | |
|
| 199 | + 111110 | 76 | 62 | 3E | |
|
| 200 | + 111101 | 75 | 61 | 3D | |
|
| 201 | + 111100 | 74 | 60 | 3C | |
|
| 202 | + 111011 | 73 | 59 | 3B | |
|
| 203 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 204 | +``` |
|
| 205 | + |
|
| 206 | +### SKIPPING VALUES |
|
| 207 | + |
|
| 208 | +With the 'by#' argument, we can cause numbers to iterate by more than 1. |
|
| 209 | +For example, if we wanted to go from 3 to 81 skipping 3 values each turn: |
|
| 210 | + |
|
| 211 | +``` |
|
| 212 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 3 81 by3 |
|
| 213 | + base 2 | base 8 | base10 | base16 | |
|
| 214 | +----------+----------+----------+----------+ |
|
| 215 | + 11 | 3 | 3 | 3 | |
|
| 216 | + 110 | 6 | 6 | 6 | |
|
| 217 | + 1001 | 11 | 9 | 9 | |
|
| 218 | + 1100 | 14 | 12 | C | |
|
| 219 | + 1111 | 17 | 15 | F | |
|
| 220 | + 10010 | 22 | 18 | 12 | |
|
| 221 | + 10101 | 25 | 21 | 15 | |
|
| 222 | + 11000 | 30 | 24 | 18 | |
|
| 223 | + 11011 | 33 | 27 | 1B | |
|
| 224 | + 11110 | 36 | 30 | 1E | |
|
| 225 | + 100001 | 41 | 33 | 21 | |
|
| 226 | + 100100 | 44 | 36 | 24 | |
|
| 227 | + 100111 | 47 | 39 | 27 | |
|
| 228 | + 101010 | 52 | 42 | 2A | |
|
| 229 | + 101101 | 55 | 45 | 2D | |
|
| 230 | + 110000 | 60 | 48 | 30 | |
|
| 231 | + 110011 | 63 | 51 | 33 | |
|
| 232 | + 110110 | 66 | 54 | 36 | |
|
| 233 | + 111001 | 71 | 57 | 39 | |
|
| 234 | + 111100 | 74 | 60 | 3C | |
|
| 235 | + 111111 | 77 | 63 | 3F | |
|
| 236 | + 1000010 | 102 | 66 | 42 | |
|
| 237 | + 1000101 | 105 | 69 | 45 | |
|
| 238 | + 1001000 | 110 | 72 | 48 | |
|
| 239 | + 1001011 | 113 | 75 | 4B | |
|
| 240 | + 1001110 | 116 | 78 | 4E | |
|
| 241 | + 1010001 | 121 | 81 | 51 | |
|
| 242 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 243 | +``` |
|
| 244 | + |
|
| 245 | +This should be flexible whether going forward or backward in count: |
|
| 246 | + |
|
| 247 | +``` |
|
| 248 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 32 2 by4 |
|
| 249 | + base 2 | base 8 | base10 | base16 | |
|
| 250 | +----------+----------+----------+----------+ |
|
| 251 | + 100000 | 40 | 32 | 20 | |
|
| 252 | + 11100 | 34 | 28 | 1C | |
|
| 253 | + 11000 | 30 | 24 | 18 | |
|
| 254 | + 10100 | 24 | 20 | 14 | |
|
| 255 | + 10000 | 20 | 16 | 10 | |
|
| 256 | + 1100 | 14 | 12 | C | |
|
| 257 | + 1000 | 10 | 8 | 8 | |
|
| 258 | + 100 | 4 | 4 | 4 | |
|
| 259 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 260 | +``` |
|
| 261 | + |
|
| 262 | +### EXCEEDING BOUNDS |
|
| 263 | + |
|
| 264 | +Although our script does not need to iterate values outside the 0-255 |
|
| 265 | +range, it does need to check and cap values that exceed these bounds. |
|
| 266 | + |
|
| 267 | +For example, if a starting or ending value falls beyond 255, cap it to |
|
| 268 | +255: |
|
| 269 | + |
|
| 270 | +``` |
|
| 271 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 250 |
|
| 272 | + base 2 | base 8 | base10 | base16 | |
|
| 273 | +----------+----------+----------+----------+ |
|
| 274 | + 11111010 | 372 | 250 | FA | |
|
| 275 | + 11111011 | 373 | 251 | FB | |
|
| 276 | + 11111100 | 374 | 252 | FC | |
|
| 277 | + 11111101 | 375 | 253 | FD | |
|
| 278 | + 11111110 | 376 | 254 | FE | |
|
| 279 | + 11111111 | 377 | 255 | FF | |
|
| 280 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 281 | +``` |
|
| 282 | + |
|
| 283 | +If we have a negative value of any sort: |
|
| 284 | + |
|
| 285 | +``` |
|
| 286 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 4 -8 |
|
| 287 | + base 2 | base 8 | base10 | base16 | |
|
| 288 | +----------+----------+----------+----------+ |
|
| 289 | + 100 | 4 | 4 | 4 | |
|
| 290 | + 11 | 3 | 3 | 3 | |
|
| 291 | + 10 | 2 | 2 | 2 | |
|
| 292 | + 1 | 1 | 1 | 1 | |
|
| 293 | + 0 | 0 | 0 | 0 | |
|
| 294 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 295 | +``` |
|
| 296 | + |
|
| 297 | +Both starting and ending values need to appropriately fall within the |
|
| 298 | +0-255 bounds, however they may be situated. |
|
| 299 | + |
|
| 300 | +### ADDITIONAL BASES |
|
| 301 | + |
|
| 302 | +Your script should also support the inclusion of additional bases (valid |
|
| 303 | +bases are any base between 2 and 16, inclusive). The default bases |
|
| 304 | +assumed included are 2, 8, 10, and 16, but additional ones may be |
|
| 305 | +specified with a **with#** argument. |
|
| 306 | + |
|
| 307 | +For instance, let's say we wanted to include base 7: |
|
| 308 | + |
|
| 309 | +``` |
|
| 310 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh with7 |
|
| 311 | + base 2 | base 7 | base 8 | base10 | base16 | |
|
| 312 | +----------+----------+----------+----------+----------+ |
|
| 313 | + 0 | 0 | 0 | 0 | 0 | |
|
| 314 | + 1 | 1 | 1 | 1 | 1 | |
|
| 315 | + 10 | 2 | 2 | 2 | 2 | |
|
| 316 | + 11 | 3 | 3 | 3 | 3 | |
|
| 317 | + 100 | 4 | 4 | 4 | 4 | |
|
| 318 | + 101 | 5 | 5 | 5 | 5 | |
|
| 319 | + 110 | 6 | 6 | 6 | 6 | |
|
| 320 | + 111 | 10 | 7 | 7 | 7 | |
|
| 321 | + 1000 | 11 | 10 | 8 | 8 | |
|
| 322 | + 1001 | 12 | 11 | 9 | 9 | |
|
| 323 | + 1010 | 13 | 12 | 10 | A | |
|
| 324 | + 1011 | 14 | 13 | 11 | B | |
|
| 325 | + 1100 | 15 | 14 | 12 | C | |
|
| 326 | + 1101 | 16 | 15 | 13 | D | |
|
| 327 | + 1110 | 20 | 16 | 14 | E | |
|
| 328 | + 1111 | 21 | 17 | 15 | F | |
|
| 329 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 330 | +``` |
|
| 331 | + |
|
| 332 | +And this should work even with the potential inclusion of starting, |
|
| 333 | +ending, or a by# option (forward or backward): |
|
| 334 | + |
|
| 335 | +``` |
|
| 336 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 13 255 by13 with7 |
|
| 337 | + base 2 | base 7 | base 8 | base10 | base16 | |
|
| 338 | +----------+----------+----------+----------+----------+ |
|
| 339 | + 1101 | 16 | 15 | 13 | D | |
|
| 340 | + 11010 | 35 | 32 | 26 | 1A | |
|
| 341 | + 100111 | 54 | 47 | 39 | 27 | |
|
| 342 | + 110100 | 103 | 64 | 52 | 34 | |
|
| 343 | + 1000001 | 122 | 101 | 65 | 41 | |
|
| 344 | + 1001110 | 141 | 116 | 78 | 4E | |
|
| 345 | + 1011011 | 160 | 133 | 91 | 5B | |
|
| 346 | + 1101000 | 206 | 150 | 104 | 68 | |
|
| 347 | + 1110101 | 225 | 165 | 117 | 75 | |
|
| 348 | + 10000010 | 244 | 202 | 130 | 82 | |
|
| 349 | + 10001111 | 263 | 217 | 143 | 8F | |
|
| 350 | + 10011100 | 312 | 234 | 156 | 9C | |
|
| 351 | + 10101001 | 331 | 251 | 169 | A9 | |
|
| 352 | + 10110110 | 350 | 266 | 182 | B6 | |
|
| 353 | + 11000011 | 366 | 303 | 195 | C3 | |
|
| 354 | + 11010000 | 415 | 320 | 208 | D0 | |
|
| 355 | + 11011101 | 434 | 335 | 221 | DD | |
|
| 356 | + 11101010 | 453 | 352 | 234 | EA | |
|
| 357 | + 11110111 | 502 | 367 | 247 | F7 | |
|
| 358 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 359 | +``` |
|
| 360 | + |
|
| 361 | +Multiple additional bases can be included... you merely append additional |
|
| 362 | +**with#** arguments: |
|
| 363 | + |
|
| 364 | +``` |
|
| 365 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 196 2 with3 by14 with12 |
|
| 366 | + base 2 | base 3 | base 8 | base10 | base12 | base16 | |
|
| 367 | +----------+----------+----------+----------+----------+----------+ |
|
| 368 | + 11000100 | 21021 | 304 | 196 | 144 | C4 | |
|
| 369 | + 10110110 | 20202 | 266 | 182 | 132 | B6 | |
|
| 370 | + 10101000 | 20020 | 250 | 168 | 120 | A8 | |
|
| 371 | + 10011010 | 12201 | 232 | 154 | 10A | 9A | |
|
| 372 | + 10001100 | 12012 | 214 | 140 | B8 | 8C | |
|
| 373 | + 1111110 | 11200 | 176 | 126 | A6 | 7E | |
|
| 374 | + 1110000 | 11011 | 160 | 112 | 94 | 70 | |
|
| 375 | + 1100010 | 10122 | 142 | 98 | 82 | 62 | |
|
| 376 | + 1010100 | 10010 | 124 | 84 | 70 | 54 | |
|
| 377 | + 1000110 | 2121 | 106 | 70 | 5A | 46 | |
|
| 378 | + 111000 | 2002 | 70 | 56 | 48 | 38 | |
|
| 379 | + 101010 | 1120 | 52 | 42 | 36 | 2A | |
|
| 380 | + 11100 | 1001 | 34 | 28 | 24 | 1C | |
|
| 381 | + 1110 | 112 | 16 | 14 | 12 | E | |
|
| 382 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 383 | +``` |
|
| 384 | + |
|
| 385 | +### OMITTING BASES |
|
| 386 | + |
|
| 387 | +With the **sans#** option, we can leave out specified bases (useful for |
|
| 388 | +excluding any of the default 2, 8, 10, or 16). |
|
| 389 | + |
|
| 390 | +Here we will omit base 8 from a default run: |
|
| 391 | + |
|
| 392 | +``` |
|
| 393 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh sans8 |
|
| 394 | + base 2 | base10 | base16 | |
|
| 395 | +----------+----------+----------+ |
|
| 396 | + 0 | 0 | 0 | |
|
| 397 | + 1 | 1 | 1 | |
|
| 398 | + 10 | 2 | 2 | |
|
| 399 | + 11 | 3 | 3 | |
|
| 400 | + 100 | 4 | 4 | |
|
| 401 | + 101 | 5 | 5 | |
|
| 402 | + 110 | 6 | 6 | |
|
| 403 | + 111 | 7 | 7 | |
|
| 404 | + 1000 | 8 | 8 | |
|
| 405 | + 1001 | 9 | 9 | |
|
| 406 | + 1010 | 10 | A | |
|
| 407 | + 1011 | 11 | B | |
|
| 408 | + 1100 | 12 | C | |
|
| 409 | + 1101 | 13 | D | |
|
| 410 | + 1110 | 14 | E | |
|
| 411 | + 1111 | 15 | F | |
|
| 412 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 413 | +``` |
|
| 414 | + |
|
| 415 | +Of course, this option can be validly mixed with any of the other valid |
|
| 416 | +options, and needs to work as appropriate (here you'll see a run we did |
|
| 417 | +prior, with the only difference being the omission of base 8): |
|
| 418 | + |
|
| 419 | +``` |
|
| 420 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh 196 2 with3 by14 with12 sans8 |
|
| 421 | + base 2 | base 3 | base10 | base12 | base16 | |
|
| 422 | +----------+----------+----------+----------+----------+ |
|
| 423 | + 11000100 | 21021 | 196 | 144 | C4 | |
|
| 424 | + 10110110 | 20202 | 182 | 132 | B6 | |
|
| 425 | + 10101000 | 20020 | 168 | 120 | A8 | |
|
| 426 | + 10011010 | 12201 | 154 | 10A | 9A | |
|
| 427 | + 10001100 | 12012 | 140 | B8 | 8C | |
|
| 428 | + 1111110 | 11200 | 126 | A6 | 7E | |
|
| 429 | + 1110000 | 11011 | 112 | 94 | 70 | |
|
| 430 | + 1100010 | 10122 | 98 | 82 | 62 | |
|
| 431 | + 1010100 | 10010 | 84 | 70 | 54 | |
|
| 432 | + 1000110 | 2121 | 70 | 5A | 46 | |
|
| 433 | + 111000 | 2002 | 56 | 48 | 38 | |
|
| 434 | + 101010 | 1120 | 42 | 36 | 2A | |
|
| 435 | + 11100 | 1001 | 28 | 24 | 1C | |
|
| 436 | + 1110 | 112 | 14 | 12 | E | |
|
| 437 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 438 | +``` |
|
| 439 | + |
|
| 440 | +Multiple **sans#** options can be given, and will cancel out any present |
|
| 441 | +base (including those specified with a **with#** option). A **sans#** |
|
| 442 | +option for a non-existent base should be silently ignored. |
|
| 443 | + |
|
| 444 | +### ONLINE HELP |
|
| 445 | + |
|
| 446 | +Your script should also, when prompted, display usage information with |
|
| 447 | +the **help** option: |
|
| 448 | + |
|
| 449 | +``` |
|
| 450 | +lab46:~/src/SEMESTER/unix/pwn0$ ./pwn0.sh help |
|
| 451 | + |
|
| 452 | + pwn0.sh - render a number table in the specified bases, |
|
| 453 | + displaying from starting value to ending value. |
|
| 454 | + |
|
| 455 | + behavior: by default, bases 2, 8, 10, and 16 will be |
|
| 456 | + displayed, in a range of 0 to 15 (inclusive). |
|
| 457 | + |
|
| 458 | + note: valid bases range from 2-16, and values should |
|
| 459 | + not go negative nor exceed 255. If a starting |
|
| 460 | + value but no ending value is given, assume an |
|
| 461 | + ending value +15 away (or capped by 255). |
|
| 462 | + |
|
| 463 | + usage: pwn0.sh [start#] [end#] [OPTION]... |
|
| 464 | + |
|
| 465 | + options: |
|
| 466 | + $1 - if a positive decimal value, override the |
|
| 467 | + starting value (0) |
|
| 468 | + $2 - if a positive decimal value, override the |
|
| 469 | + ending value (15) |
|
| 470 | + |
|
| 471 | + other options: |
|
| 472 | + by# - iterate through values by # (default: 1) |
|
| 473 | + with# - include base # in the list of bases to display |
|
| 474 | + sans# - remove base # in the list of bases to display |
|
| 475 | + help - display script usage and exit |
|
| 476 | + |
|
| 477 | +lab46:~/src/SEMESTER/unix/pwn0$ |
|
| 478 | +``` |
|
| 479 | + |
|
| 480 | +## SPECIFICATIONS |
|
| 481 | + |
|
| 482 | +Evaluation will be based on correctness of values as well as on |
|
| 483 | +formatting/spacing. |
|
| 484 | + |
|
| 485 | +You'll notice that everything lines up and is positioned similarly: |
|
| 486 | + |
|
| 487 | + * each column exists within 10 characters of on-screen real estate: |
|
| 488 | + * 8 characters for actual value display, |
|
| 489 | + * with one space padding either side |
|
| 490 | + * columns are separated with a `|` symbol, appended to the right edge of the column (effectively making each column 11 characters wide). |
|
| 491 | + * note that the rightmost column is ended with this `|`. |
|
| 492 | + * there is a heading/header at the top of the output table, and it uses a '**+**' to "connect" the horizontal and vertical lines being drawn |
|
| 493 | + * The dashes and vertical bars set up an ASCII art-like table pattern that helps make the data more readable. |
|
| 494 | + * The values are right justified with each column |
|
| 495 | + * justification is essential. Everything should line up on its respective right margin. |
|
| 496 | + * base headings are right justified, with a 2 spaces being allocated for reference of the base: |
|
| 497 | + * you'll see "base 2" vs. "base16"; your script needs to accommodate this. |
|
| 498 | + * You are to literally print out no more than 2 consecutive spaces at a time in your output statements. If you need more, use one of the formatting tools to generate spaces for you (**printf(1)** may be able to help you with this). |
|
| 499 | + * You need to check your arguments to ensure they are present and valid. Some examples: |
|
| 500 | + * starting value is a valid (whole) number |
|
| 501 | + * if less than 0, or greater than 255, needs to be capped to whichever extreme it exceeds |
|
| 502 | + * if -4, cap to 0 |
|
| 503 | + * if 300, cap to 255 |
|
| 504 | + * ending value is a valid (whole) number |
|
| 505 | + * if less than 0, or greater than 255, needs to be capped to whichever extreme it exceeds |
|
| 506 | + * if -8, cap to 0 |
|
| 507 | + * if 420, cap to 255 |
|
| 508 | + * any invalid arguments (nonsensical value in place of starting value, invalid base specification, etc.) should be silently dropped/ignored. |
|
| 509 | + * default starting value is 0, default ending value is 15. If nothing else is validly provided, these are the values the script should run with. |
|
| 510 | + * if starting and ending values are the same, the script will display just one line of number output (in addition to the header). |
|
| 511 | + * if lacking any bases to display, silently exit |
|
| 512 | + * your script needs to commence with a proper **shabang** to bash; your script needs to end with an "**exit 0**" at the very end |
|
| 513 | + * comments and indentation are required and necessary |
|
| 514 | + * comments should explain how or why you are doing something |
|
| 515 | + * indentation should be consistent throughout the script |
|
| 516 | + * indentation is to be no less than 3 on-screen spaces (I recommend tabstops of 4). |
|
| 517 | + * continuing with our shell scripting, your script will need to employ in a core/central way: |
|
| 518 | + * variables |
|
| 519 | + * command expansions |
|
| 520 | + * regular expressions |
|
| 521 | + * if statements |
|
| 522 | + * loops |
|
| 523 | + * your logic needs to: |
|
| 524 | + * flow (one thing leads into the next, as best as possible) |
|
| 525 | + * make sense within the given context |
|
| 526 | + * avoid redundancy |
|
| 527 | + * be understood by you (no grabbing snippets that seem to "work" from the internet) |
|
| 528 | + * if you gain inspiration from some external resource, please cite it |
|
| 529 | + * comments are a great way of demonstrating understanding (if you explain the why and how effectively, and it isn't in violation of other aspects, I'll know you are in control of things) |
|
| 530 | + |
|
| 531 | +To be sure, I'll be checking to make sure you solution follows the spirit |
|
| 532 | +of what this project is about (that you implement functional, flowing |
|
| 533 | +logic utilizing the tools and concepts we've learned, in an application |
|
| 534 | +that helps demonstrate your comprehension). Don't try to weasel your way |
|
| 535 | +out of this or cut corners. This is an opportunity to further solidify |
|
| 536 | +your proficiency with everything. |
|
| 537 | + |
|
| 538 | +## SPIRIT OF PROJECT |
|
| 539 | + |
|
| 540 | +The spirit of the project embodies many aspects we've been focusing on |
|
| 541 | +throughout the semester: |
|
| 542 | + |
|
| 543 | + * recognizing patterns to employ effective solutions in problem solving |
|
| 544 | + * utilizing concepts and tools covered |
|
| 545 | + * demonstrating comprehension of concepts, tools, and problems |
|
| 546 | + * employing concepts in knowledgeable and thoughtful manner |
|
| 547 | + * following instructions |
|
| 548 | + * implementing to specifications |
|
| 549 | + * utilizing creativity |
|
| 550 | + * being able to control solution via consistent, clear, and organized presentation |
|
| 551 | + |
|
| 552 | +Basically: I want your solution to be the result of an honest, genuine |
|
| 553 | +brainstorming process where you have (on your own) figured out a path to |
|
| 554 | +solving the problem, you have dabbled and experimented and figured things |
|
| 555 | +out, and you can command the concepts and tools with a fluency enabling |
|
| 556 | +you to pull off such a feat. Your solution should demonstrate the real |
|
| 557 | +learning that took place and experience gained. |
|
| 558 | + |
|
| 559 | +Cutting corners, avoiding work, skimping on functionality, cheating |
|
| 560 | +through getting others to do work for you or finding pre-packaged |
|
| 561 | +"answers" on the internet violates the spirit of the project, for they |
|
| 562 | +betray your ability to pull off the task on your own. |
|
| 563 | + |
|
| 564 | +NOTE: some have instantiated controversy in the past by utilizing AI in a |
|
| 565 | +manner well beyond their abilities. In such cases, submitted work is not |
|
| 566 | +considered your own, and thereby inviting disciplinary action. Don't fall |
|
| 567 | +into that trap. |
|
| 568 | + |
|
| 569 | +### IDENTIFYING SHORTCOMINGS |
|
| 570 | + |
|
| 571 | +I would also like it if you provided an inventory of what functionality |
|
| 572 | +is lacking or out of spec when you submit the project. The better you can |
|
| 573 | +describe your deviations from stated requirements, the more forgiving I |
|
| 574 | +may be during evaluation (versus trying to hide the shortcomings and |
|
| 575 | +hoping I do not discover them). |
|
| 576 | + |
|
| 577 | +The more fluent you are in describing your shortcomings on accomplishing |
|
| 578 | +the project (ie "I didn't know how to do this" is far from fluent), the |
|
| 579 | +better I will be able to gauge your understanding on a particular aspect. |
|
| 580 | + |
|
| 581 | +This can be in the form of comments in your script, or even a separate |
|
| 582 | +file submitted at time of submission (if a file, be sure to make mention |
|
| 583 | +of it in your script so I can be sure to look for it). |
|
| 584 | + |
|
| 585 | +### OUTPUT FORMATTING WITH printf(1) |
|
| 586 | + |
|
| 587 | +You might be wondering how you can pull off some of these output |
|
| 588 | +formatting feats. The **echo** command, after all, is rather rudimentary. |
|
| 589 | + |
|
| 590 | +Fear not! The **printf(1)** tool comes to your rescue! |
|
| 591 | + |
|
| 592 | +Like **echo**, **printf** displays information to the screen (STDOUT). In |
|
| 593 | +fact, various programming languages (like C and C++) that want more |
|
| 594 | +powerful output formatting implement some form of printf into their vast |
|
| 595 | +libraries. |
|
| 596 | + |
|
| 597 | +Be sure to check the manual page for options and functionality; following |
|
| 598 | +will be a few usage examples. |
|
| 599 | + |
|
| 600 | +### printf: BASIC OPERATION |
|
| 601 | + |
|
| 602 | +Like **echo**, **printf** in its simplest form takes as an argument a |
|
| 603 | +string to display to STDOUT: |
|
| 604 | + |
|
| 605 | +``` |
|
| 606 | +lab46:~$ printf "Hello, World" |
|
| 607 | +Hello, Worldlab46:~$ |
|
| 608 | +``` |
|
| 609 | + |
|
| 610 | +However, we notice one difference between the default behavior of |
|
| 611 | +**printf** vs. **echo**: **printf** does not automatically issue a |
|
| 612 | +newline by default, as **echo** does. So, we'll need to specify it |
|
| 613 | +manually with the **\n** character: |
|
| 614 | + |
|
| 615 | +``` |
|
| 616 | +lab46:~$ printf "Hello, World\n" |
|
| 617 | +Hello, World |
|
| 618 | +lab46:~$ |
|
| 619 | +``` |
|
| 620 | + |
|
| 621 | +Those various escape characters we've learned about? Super useful here: |
|
| 622 | + |
|
| 623 | + * **\n** - newline |
|
| 624 | + * **\t** - tab |
|
| 625 | + |
|
| 626 | +Be sure to check the manual page for additional escape characters. |
|
| 627 | + |
|
| 628 | +### printf: FORMAT SPECIFIERS |
|
| 629 | + |
|
| 630 | +Now, we know from using **echo** we can utilize shell variable and |
|
| 631 | +command expansions to make our output more dynamic. |
|
| 632 | + |
|
| 633 | +But, **printf** adds additional formatting capability that **echo** |
|
| 634 | +lacks. If the string we are displaying contains **%** symbols, |
|
| 635 | +substitutions can be made and behaviors invoked; functionality that |
|
| 636 | +**echo** lacks. |
|
| 637 | + |
|
| 638 | +Some common format specifiers: |
|
| 639 | + |
|
| 640 | + * **%d** - substitute integer (whole number) value |
|
| 641 | + * **%s** - substitute string value |
|
| 642 | + * **%c** - substitute single character |
|
| 643 | + * **%f** - substitute floating point value |
|
| 644 | + * **%o** - substitute integer (whole number) value and represent in octal |
|
| 645 | + * **%x** - substitute integer (whole number) value and represent in hexadecimal |
|
| 646 | + |
|
| 647 | +First up, a simple example: |
|
| 648 | + |
|
| 649 | +``` |
|
| 650 | +lab46:~$ printf "%d\n" 175 |
|
| 651 | +175 |
|
| 652 | +lab46:~$ |
|
| 653 | +``` |
|
| 654 | + |
|
| 655 | +Then, adding to it: |
|
| 656 | + |
|
| 657 | +``` |
|
| 658 | +lab46:~$ printf "The number: %d\n" 175 |
|
| 659 | +The number: 175 |
|
| 660 | +lab46:~$ |
|
| 661 | +``` |
|
| 662 | + |
|
| 663 | +That 175 can also be in a variable: |
|
| 664 | + |
|
| 665 | +``` |
|
| 666 | +lab46:~$ value=175 |
|
| 667 | +lab46:~$ printf "The number: %d\n" ${value} |
|
| 668 | +The number: 175 |
|
| 669 | +lab46:~$ |
|
| 670 | +``` |
|
| 671 | + |
|
| 672 | +You may want to wrap the variable in double quotes, to avoid cases where |
|
| 673 | +it might be NULL and otherwise generate an error (I generally quote all |
|
| 674 | +my variables to be on the safe side). |
|
| 675 | + |
|
| 676 | +How about substitutions with strings? |
|
| 677 | + |
|
| 678 | +``` |
|
| 679 | +lab46:~$ printf "Your username is: %s\n" "${USER}" |
|
| 680 | +Your username is: username |
|
| 681 | +lab46:~$ |
|
| 682 | +``` |
|
| 683 | + |
|
| 684 | +And in general just crafting super effective format strings: |
|
| 685 | + |
|
| 686 | +``` |
|
| 687 | +lab46:~$ value=175 |
|
| 688 | +lab46:~$ printf "%d %s %X\n" "${value}" "is hexadecimal" "${value}" |
|
| 689 | +175 is hexadecimal AF |
|
| 690 | +lab46:~$ |
|
| 691 | +``` |
|
| 692 | + |
|
| 693 | +Please take note, where there are multiple format specifiers, |
|
| 694 | +substitution is in order of specification... **%d** was the first, **%s** |
|
| 695 | +was the second, and **%X** was the third in that particular string, so |
|
| 696 | +the first value following the string is grabbed by the **%d**, the next |
|
| 697 | +the **%s**, and the third the **%X**. Ordering matters (which should make |
|
| 698 | +sense). |
|
| 699 | + |
|
| 700 | +### printf: OUTPUT FORMATTING |
|
| 701 | + |
|
| 702 | +So now, getting to where **printf** really excels, formatting your |
|
| 703 | +output. |
|
| 704 | + |
|
| 705 | +It turns out, that between the **%** and whatever format option you |
|
| 706 | +specify, you can provide a numeric value which will impact how that |
|
| 707 | +number appears on the screen, commonly in the form of preallocated space |
|
| 708 | +to display within. |
|
| 709 | + |
|
| 710 | +For instance: |
|
| 711 | + |
|
| 712 | +``` |
|
| 713 | +lab46:~$ printf "Testing: >>%4d<<\n" 47 |
|
| 714 | +Testing: >> 47<< |
|
| 715 | +lab46:~$ |
|
| 716 | +``` |
|
| 717 | + |
|
| 718 | +See what happened there? 47 was displayed, but WITHIN a block of 4 |
|
| 719 | +characters. Also of note, by default output is **right justified**. |
|
| 720 | + |
|
| 721 | +To **left** justify, simply make it negative: |
|
| 722 | + |
|
| 723 | +``` |
|
| 724 | +lab46:~$ printf "Testing: >>%-4d<<\n" 47 |
|
| 725 | +Testing: >>47 << |
|
| 726 | +lab46:~$ |
|
| 727 | +``` |
|
| 728 | + |
|
| 729 | +We can also pad with zeros, that is represented by decimal values: |
|
| 730 | + |
|
| 731 | +``` |
|
| 732 | +lab46:~$ printf "Testing: >>%.3d<<\n" 49 |
|
| 733 | +Testing: >>049<< |
|
| 734 | +lab46:~$ |
|
| 735 | +``` |
|
| 736 | + |
|
| 737 | +This can be combined with justify and space allocation: |
|
| 738 | + |
|
| 739 | +``` |
|
| 740 | +lab46:~$ printf "Testing: >>%-6.3d<<\n" 49 |
|
| 741 | +Testing: >>049 << |
|
| 742 | +lab46:~$ |
|
| 743 | +``` |
|
| 744 | + |
|
| 745 | +Other neat tricks? We can variable-ize the padding by using a |
|
| 746 | +`*`: |
|
| 747 | + |
|
| 748 | +``` |
|
| 749 | +lab46:~$ spacing=4 |
|
| 750 | +lab46:~$ printf "Testing: >>%*d<<\n" "${spacing}" 49 |
|
| 751 | +Testing: >> 49<< |
|
| 752 | +lab46:~$ |
|
| 753 | +``` |
|
| 754 | + |
|
| 755 | +The **printf** tool is super-powerful and useful for output, so mastering |
|
| 756 | +its use adds an impressive capability to your repertoire. |
|
| 757 | + |
|
| 758 | +Play with **printf** and experiment... you'll find it can accomplish some |
|
| 759 | +impressive output feats that previously may have been more complicated. |
|
| 760 | + |
|
| 761 | +## SELECTION |
|
| 762 | + |
|
| 763 | +Occasionally during the automation of a task, you will have need for the |
|
| 764 | +computer to make a decision based on the state of a condition to decide |
|
| 765 | +how to proceed. We accomplish this via the **if** selection structure. |
|
| 766 | + |
|
| 767 | +In bash, an **if** takes the following form: |
|
| 768 | + |
|
| 769 | +``` |
|
| 770 | +if [ condition ]; then |
|
| 771 | + statement(s) |
|
| 772 | +fi |
|
| 773 | +``` |
|
| 774 | + |
|
| 775 | +The "condition" are valid arguments posed to the `[`(1) command, |
|
| 776 | +resulting in a true or false result. |
|
| 777 | + |
|
| 778 | +There are one or more statements within the body of the if (to be run in |
|
| 779 | +the event the result of the condition tests true), and the structure is |
|
| 780 | +terminated with the trailing **fi** (if spelled backwards). |
|
| 781 | + |
|
| 782 | +We also have the ability to react in the event the **if** condition tests |
|
| 783 | +false, and that is with an optional **else** statement (which is used 0 |
|
| 784 | +or 1 times per if, and must always follow the if): |
|
| 785 | + |
|
| 786 | +``` |
|
| 787 | +if [ condition ]; then |
|
| 788 | + statement(s) |
|
| 789 | +else |
|
| 790 | + statement(s) |
|
| 791 | +fi |
|
| 792 | +``` |
|
| 793 | + |
|
| 794 | +The **else** has no condition: it is a reaction to the previously tested |
|
| 795 | +condition being false. |
|
| 796 | + |
|
| 797 | +### CONDITIONS |
|
| 798 | + |
|
| 799 | +The conditions we pose to the computer must be such that resolve |
|
| 800 | +ultimately to a true or false result. |
|
| 801 | + |
|
| 802 | +Each condition can be unary or binary in nature, meaning we can directly |
|
| 803 | +check the state of one thing, or compare the relationship between two |
|
| 804 | +things. |
|
| 805 | + |
|
| 806 | +For example, the **-z** argument to **[**(**1**) tests for a NULL string. |
|
| 807 | +If we wanted to see if a variable as a result of some operation were NULL |
|
| 808 | +or populated, we could do: |
|
| 809 | + |
|
| 810 | +``` |
|
| 811 | +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$') |
|
| 812 | +if [ -z "${check}" ]; then |
|
| 813 | + statement(s) # do this if check is NULL |
|
| 814 | +fi |
|
| 815 | +``` |
|
| 816 | + |
|
| 817 | +Note that we could also check the opposite. We can use the **!** symbol |
|
| 818 | +to require the opposite (NOT): |
|
| 819 | + |
|
| 820 | +``` |
|
| 821 | +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$') |
|
| 822 | +if [ ! -z "${check}" ]; then |
|
| 823 | + statement(s) # do this if check is NOT NULL |
|
| 824 | +fi |
|
| 825 | +``` |
|
| 826 | + |
|
| 827 | +Comparing two strings, the two common scenarios we tend to care about is |
|
| 828 | +whether or not the two strings are equal or not equal: |
|
| 829 | + |
|
| 830 | +``` |
|
| 831 | +string1="blah" |
|
| 832 | +string2="boop" |
|
| 833 | + |
|
| 834 | +if [ "${string1}" = "${string2}" ]; then |
|
| 835 | + statement(s) # do this in the event strings are equal |
|
| 836 | +fi |
|
| 837 | + |
|
| 838 | +if [ ! "${string1}" = "${string2}" ]; then |
|
| 839 | + statement(s) # do this in the event strings are NOT equal |
|
| 840 | +fi |
|
| 841 | +``` |
|
| 842 | + |
|
| 843 | +It should be stated that instead of negating the result, we could also |
|
| 844 | +just use an **else** clause: |
|
| 845 | + |
|
| 846 | +``` |
|
| 847 | +string1="blah" |
|
| 848 | +string2="boop" |
|
| 849 | + |
|
| 850 | +if [ "${string1}" = "${string2}" ]; then |
|
| 851 | + statement(s) # do this in the event strings are equal |
|
| 852 | +else |
|
| 853 | + statement(s) # do this in the event strings are not equal |
|
| 854 | +fi |
|
| 855 | +``` |
|
| 856 | + |
|
| 857 | +As a matter of style (and to potentially avoid syntax/logic errors being |
|
| 858 | +committed), one should not pose a condition just for the sake of ensuring |
|
| 859 | +its opposite (ie no empty clauses). |
|
| 860 | + |
|
| 861 | +If comparing numerical values, especially in numerical contexts, we have |
|
| 862 | +a set of arguments we can choose from: |
|
| 863 | + |
|
| 864 | + * **-eq** - is equal to |
|
| 865 | + * **-ne** - is not equal to |
|
| 866 | + * **-lt** - is less than |
|
| 867 | + * **-le** - is less than or equal to |
|
| 868 | + * **-gt** - is greater than |
|
| 869 | + * **-ge** - is greater than or equal to |
|
| 870 | + |
|
| 871 | +These of course are binary conditions, meaning we compare TWO variables |
|
| 872 | +to see if they possess the indicated relation (which results in a true or |
|
| 873 | +false result produced). |
|
| 874 | + |
|
| 875 | +## LOOPS |
|
| 876 | + |
|
| 877 | +When you have a section of code you would like to repeat some number of |
|
| 878 | +times, a loop can be used to achieve this. |
|
| 879 | + |
|
| 880 | +Here we will explore the **while** conditional loop. If an if statement |
|
| 881 | +can run 0 or 1 times, a while loop can run 0 or more. |
|
| 882 | + |
|
| 883 | +``` |
|
| 884 | +count=10 |
|
| 885 | +while [ "${count}" -gt 0 ]; do |
|
| 886 | + echo "count is: ${count}" |
|
| 887 | +``` |
|
| 888 | + |
|
| 889 | +=====Submission===== |
|
| 890 | + |
|
| 891 | +By successfully performing this project, you should have a fully |
|
| 892 | +functioning script by the name of **pwn0.sh**, which is all you need to |
|
| 893 | +submit for project completion (no steps file, as your "steps" file IS the |
|
| 894 | +script you wrote). |
|
| 895 | + |
|
| 896 | +To submit this project to me using the **submit** tool, run the following |
|
| 897 | +command at your lab46 prompt: |
|
| 898 | + |
|
| 899 | +``` |
|
| 900 | +$ submit unix pwn0 pwn0.sh |
|
| 901 | +Submitting unix project "pwn0": |
|
| 902 | + -> pwn0.sh(OK) |
|
| 903 | + |
|
| 904 | +SUCCESSFULLY SUBMITTED |
|
| 905 | +``` |
|
| 906 | + |
|
| 907 | +You should get some sort of confirmation indicating successful submission |
|
| 908 | +if all went according to plan. If not, check for typos and or locational |
|
| 909 | +mismatches. |
|
| 910 | + |
|
| 911 | +I'll be looking for the following: |
|
| 912 | + |
|
| 913 | +``` |
|
| 914 | +312:pwn0:final tally of results (312/312) |
|
| 915 | +*:pwn0:pwn0.sh on help displays informative usage and exits [18/18] |
|
| 916 | +*:pwn0:pwn0.sh effectively utilizes variables in operations [18/18] |
|
| 917 | +*:pwn0:pwn0.sh effectively utilizes command expansions [18/18] |
|
| 918 | +*:pwn0:pwn0.sh effectively utilizes regular expressions [18/18] |
|
| 919 | +*:pwn0:pwn0.sh effectively utilizes selection statements [18/18] |
|
| 920 | +*:pwn0:pwn0.sh effectively utilizes looping structures [18/18] |
|
| 921 | +*:pwn0:pwn0.sh is a proper bash script with shabang and exit [17/17] |
|
| 922 | +*:pwn0:pwn0.sh parses command-line arguments as appropriate [17/17] |
|
| 923 | +*:pwn0:pwn0.sh accurately displays values in proper alignment [17/17] |
|
| 924 | +*:pwn0:pwn0.sh accurately displays values in requested bases [17/17] |
|
| 925 | +*:pwn0:pwn0.sh accurately displays values in specified range [17/17] |
|
| 926 | +*:pwn0:pwn0.sh range logic flexibly works forward and reverse [17/17] |
|
| 927 | +*:pwn0:pwn0.sh iterates as appropriate in given scenarios [17/17] |
|
| 928 | +*:pwn0:pwn0.sh includes additional bases as requested [17/17] |
|
| 929 | +*:pwn0:pwn0.sh omits specified bases as requested [17/17] |
|
| 930 | +*:pwn0:pwn0.sh properly manages input violations [17/17] |
|
| 931 | +*:pwn0:pwn0.sh operates according to specifications [17/17] |
|
| 932 | +*:pwn0:pwn0.sh logic is organized and easy to read [17/17] |
|
| 933 | +``` |
|
| 934 | + |
|
| 935 | +Additionally: |
|
| 936 | + * Solutions not abiding by **SPIRIT** of project will be subject to a 25% overall deduction |
|
| 937 | + * Solutions not utilizing descriptive why and how **COMMENTS** will be subject to a 25% overall deduction |
|
| 938 | + * Solutions not utilizing **INDENTATION** to promote scope and clarity will be subject to a 25% overall deduction |
|
| 939 | + * Solutions lacking **ORGANIZATION** ior are not easy to read (within 90 char width) are subject to a 25% overall deduction |
haas/fall2026/unix/projects/upf0.md
| ... | ... | @@ -0,0 +1,462 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: UNIX PIPE FUN (upf0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To continue to cultivate your problem solving skills, to practice your |
|
| 8 | +shell skills, and to demonstrate your basic scripting skills. |
|
| 9 | + |
|
| 10 | +## BACKGROUND |
|
| 11 | + |
|
| 12 | +Pipes and command expansions are important concepts and skills that you |
|
| 13 | +need to be familiar with as we proceed down the shell scripting rabbit |
|
| 14 | +hole. |
|
| 15 | + |
|
| 16 | +This project has us playing with various examples that will require |
|
| 17 | +regular use of these skills, for the purpose of throwing numbers and |
|
| 18 | +math operations together to produce desired results (and in desired |
|
| 19 | +composition). |
|
| 20 | + |
|
| 21 | +It can be helpful to fully read and understand the instructions |
|
| 22 | +associated with resources. This can take the form of comments in a source |
|
| 23 | +code or configuration file, or even actual instructions. If you see |
|
| 24 | +conspicuously-named files hinting at some action that you can take, you |
|
| 25 | +may want to investigate said file to see if it might aid you in some |
|
| 26 | +capacity. |
|
| 27 | + |
|
| 28 | +## SELECTION |
|
| 29 | + |
|
| 30 | +Occasionally during the automation of a task, you will have need for the |
|
| 31 | +computer to make a decision based on the state of a condition to decide |
|
| 32 | +how to proceed. We accomplish this via the **if** selection structure. |
|
| 33 | + |
|
| 34 | +In bash, an **if** takes the following form: |
|
| 35 | + |
|
| 36 | +``` |
|
| 37 | +if [ condition ]; then |
|
| 38 | + statement(s) |
|
| 39 | +fi |
|
| 40 | +``` |
|
| 41 | + |
|
| 42 | +The "condition" are valid arguments posed to the `[`(1) command, |
|
| 43 | +resulting in a true or false result. |
|
| 44 | + |
|
| 45 | +There are one or more statements within the body of the if (to be run in |
|
| 46 | +the event the result of the condition tests true), and the structure is |
|
| 47 | +terminated with the trailing **fi** (if spelled backwards). |
|
| 48 | + |
|
| 49 | +We also have the ability to react in the event the **if** condition tests |
|
| 50 | +false, and that is with an optional **else** statement (which is used 0 |
|
| 51 | +or 1 times per if, and must always follow the if): |
|
| 52 | + |
|
| 53 | +``` |
|
| 54 | +if [ condition ]; then |
|
| 55 | + statement(s) |
|
| 56 | +else |
|
| 57 | + statement(s) |
|
| 58 | +fi |
|
| 59 | +``` |
|
| 60 | + |
|
| 61 | +The **else** has no condition: it is a reaction to the previously tested |
|
| 62 | +condition being false. |
|
| 63 | + |
|
| 64 | +## CONDITIONS |
|
| 65 | + |
|
| 66 | +The conditions we pose to the computer must be such that resolve |
|
| 67 | +ultimately to a true or false result. |
|
| 68 | + |
|
| 69 | +Each condition can be unary or binary in nature, meaning we can directly |
|
| 70 | +check the state of one thing, or compare the relationship between two |
|
| 71 | +things. |
|
| 72 | + |
|
| 73 | +For example, the `-z` argument to `[`(1) tests for a NULL string. If we |
|
| 74 | +wanted to see if a variable as a result of some operation were NULL or |
|
| 75 | +populated, we could do: |
|
| 76 | + |
|
| 77 | +``` |
|
| 78 | +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$') |
|
| 79 | +if [ -z "${check}" ]; then |
|
| 80 | + statement(s) # do this if check is NULL |
|
| 81 | +fi |
|
| 82 | +``` |
|
| 83 | + |
|
| 84 | +Note that we could also check the opposite. We can use the **!** symbol |
|
| 85 | +to require the opposite (NOT): |
|
| 86 | + |
|
| 87 | +``` |
|
| 88 | +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$') |
|
| 89 | +if [ ! -z "${check}" ]; then |
|
| 90 | + statement(s) # do this if check is NOT NULL |
|
| 91 | +fi |
|
| 92 | +``` |
|
| 93 | + |
|
| 94 | +Comparing two strings, the two common scenarios we tend to care about is |
|
| 95 | +whether or not the two strings are equal or not equal: |
|
| 96 | + |
|
| 97 | +``` |
|
| 98 | +string1="blah" |
|
| 99 | +string2="boop" |
|
| 100 | + |
|
| 101 | +if [ "${string1}" = "${string2}" ]; then |
|
| 102 | + statement(s) # do this in the event strings are equal |
|
| 103 | +fi |
|
| 104 | + |
|
| 105 | +if [ ! "${string1}" = "${string2}" ]; then |
|
| 106 | + statement(s) # do this in the event strings are NOT equal |
|
| 107 | +fi |
|
| 108 | +``` |
|
| 109 | + |
|
| 110 | +It should be stated that instead of negating the result, we could also |
|
| 111 | +just use an **else** clause: |
|
| 112 | + |
|
| 113 | +``` |
|
| 114 | +string1="blah" |
|
| 115 | +string2="boop" |
|
| 116 | + |
|
| 117 | +if [ "${string1}" = "${string2}" ]; then |
|
| 118 | + statement(s) # do this in the event strings are equal |
|
| 119 | +else |
|
| 120 | + statement(s) # do this in the event strings are not equal |
|
| 121 | +fi |
|
| 122 | +``` |
|
| 123 | + |
|
| 124 | +As a matter of style (and to potentially avoid syntax/logic errors being |
|
| 125 | +committed), one should not pose a condition just for the sake of ensuring |
|
| 126 | +its opposite (ie no empty clauses). |
|
| 127 | + |
|
| 128 | +If comparing numerical values, especially in numerical contexts, we have |
|
| 129 | +a set of arguments we can choose from: |
|
| 130 | + |
|
| 131 | + * **-eq** - is equal to |
|
| 132 | + * **-ne** - is not equal to |
|
| 133 | + * **-lt** - is less than |
|
| 134 | + * **-le** - is less than or equal to |
|
| 135 | + * **-gt** - is greater than |
|
| 136 | + * **-ge** - is greater than or equal to |
|
| 137 | + |
|
| 138 | +These of course are binary conditions, meaning we compare TWO variables |
|
| 139 | +to see if they possess the indicated relation (which results in a true or |
|
| 140 | +false result produced). |
|
| 141 | + |
|
| 142 | +## LOOPS |
|
| 143 | + |
|
| 144 | +When you have a section of code you would like to repeat some number of |
|
| 145 | +times, a loop can be used to achieve this. |
|
| 146 | + |
|
| 147 | +Here we will explore the **while** conditional loop. If an if statement |
|
| 148 | +can run 0 or 1 times, a while loop can run 0 or more. |
|
| 149 | + |
|
| 150 | +``` |
|
| 151 | +count=10 |
|
| 152 | +while [ "${count}" -gt 0 ]; do |
|
| 153 | + echo "count is: ${count}" |
|
| 154 | + let count=count-1 |
|
| 155 | +done |
|
| 156 | +``` |
|
| 157 | + |
|
| 158 | +A couple changes from the if syntax: we use **do** to open the body, and |
|
| 159 | +**done** to resolve it. There's also no else-type countercase logic |
|
| 160 | +available. The loop is either running, or it terminates. |
|
| 161 | + |
|
| 162 | +To be sure, we can also run while loops on string comparisons: |
|
| 163 | + |
|
| 164 | +``` |
|
| 165 | +value="true" |
|
| 166 | +while [ ! "${value}" = "false" ]; do |
|
| 167 | + statement(s) |
|
| 168 | + if [ condition ]; then |
|
| 169 | + value="false" |
|
| 170 | + fi |
|
| 171 | + other_statement(s) |
|
| 172 | +done |
|
| 173 | +``` |
|
| 174 | + |
|
| 175 | +## NO GRABIT |
|
| 176 | + |
|
| 177 | +As part of this activity is to test your ability to navigate around the |
|
| 178 | +filesystem and manipulate files on your own, there is no grabit |
|
| 179 | +configured for this project. |
|
| 180 | + |
|
| 181 | +Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your |
|
| 182 | +project files back into your repository. |
|
| 183 | + |
|
| 184 | +## GET STARTED |
|
| 185 | + |
|
| 186 | +This week's project has 2 points of origin. |
|
| 187 | + |
|
| 188 | +First, in the **upf0/** sub-directory of the UNIX Public Directory, you |
|
| 189 | +will find the following archive: |
|
| 190 | + |
|
| 191 | + * **numbers.tgz** |
|
| 192 | + |
|
| 193 | +Then, under a directory by the name of your username within that same |
|
| 194 | +directory, there will be another file: |
|
| 195 | + |
|
| 196 | + * **TASK** |
|
| 197 | + |
|
| 198 | +Copy both of these files into your project directory. |
|
| 199 | + |
|
| 200 | +The **TASK** file will contain the particular command-line equations you |
|
| 201 | +have to perform, along with their stated constraints. |
|
| 202 | + |
|
| 203 | +The **numbers.tgz** file needs to be extracted, compiled, and installed; |
|
| 204 | +there is a README file located within the archive with further |
|
| 205 | +instructions on how to do this. |
|
| 206 | + |
|
| 207 | +Next, you will want to grab the latest version of the **pipemath** suite |
|
| 208 | +from the following URL: |
|
| 209 | + |
|
| 210 | + * https://lab46.g7n.org/~wedge/projects/pipemath/ |
|
| 211 | + |
|
| 212 | +You will want to use a tool like **wget(1)** or **curl(1)** to |
|
| 213 | +non-interactively download it into your work directory, and similarly |
|
| 214 | +extract, compile, and install that (check its own README file). |
|
| 215 | + |
|
| 216 | +There may be multiple versions of **pipemath** available at the download |
|
| 217 | +link. Unless you have specific reason otherwise (for this project, you do |
|
| 218 | +not), you want to go for the latest version, which will be reflected by |
|
| 219 | +the most recent datestamp encoded in the file's name. |
|
| 220 | + |
|
| 221 | +For example, say you have the following: |
|
| 222 | + |
|
| 223 | + * pipemath-20160731-10.tar.gz |
|
| 224 | + * pipemath-20161024-14.tar.gz |
|
| 225 | + * pipemath-20170123-13.tar.gz |
|
| 226 | + * pipemath-20170201-09.tar.gz |
|
| 227 | + * pipemath-20210321-17.tar.gz |
|
| 228 | + * pipemath-20220401-02.tar.gz |
|
| 229 | + |
|
| 230 | +From visual inspection, you would select the "20220401-02" one, because |
|
| 231 | +the date it encodes (April 1st, 2022 at 2am) is the most recent in that |
|
| 232 | +group. You will find this to be a common practice with many software |
|
| 233 | +projects on the internet. |
|
| 234 | + |
|
| 235 | +Note, however, that visual inspection alone is not good enough for your |
|
| 236 | +steps file. New versions may be released, and your steps file needs to |
|
| 237 | +obtain the most recent version available. To facilitate this task, the |
|
| 238 | +latest and greatest version of pipemath will be listed in a text file |
|
| 239 | +called "LATEST" (which you should see near the top of the directory index |
|
| 240 | +listing). You can make use of this file to assist you in automating the |
|
| 241 | +process of determining and downloading the latest version of the pipemath |
|
| 242 | +tools. |
|
| 243 | + |
|
| 244 | +Once those two steps are complete, you can begin on the tasks listed in |
|
| 245 | +your **TASK** file. |
|
| 246 | + |
|
| 247 | +### NUMBERS SUITE |
|
| 248 | + |
|
| 249 | +The numbers suite is basically a collection of command-line tools whose |
|
| 250 | +purpose is to display a single digit number, in accordance with the |
|
| 251 | +tool's name. |
|
| 252 | + |
|
| 253 | +For example, when you run the **zero** tool, a **0** is displayed. For |
|
| 254 | +**one**, a **1** is displayed. And so on up through **nine**. |
|
| 255 | + |
|
| 256 | +You are to use these tools for producing the numbers needed for |
|
| 257 | +calculation, and only these tools. |
|
| 258 | + |
|
| 259 | +Note that they may have a default mode of operation, which may be |
|
| 260 | +inconvenient or incompatible with what other tools or facilities require |
|
| 261 | +for normal operation. If you read the instructions you can determine how |
|
| 262 | +to alter this default behaviour at runtime. |
|
| 263 | + |
|
| 264 | +### PIPEMATH SUITE |
|
| 265 | + |
|
| 266 | +The pipemath suite is a collection of command-line tools that perform |
|
| 267 | +various basic math operations you may find useful for this project. The |
|
| 268 | +tools include: |
|
| 269 | + |
|
| 270 | + * **plus** - addition |
|
| 271 | + * **minus** - subtraction |
|
| 272 | + * **multby** - multiplication |
|
| 273 | + * **divideby** - division |
|
| 274 | + * **modulus** - modulus/remainder |
|
| 275 | + * **abs** - absolute value |
|
| 276 | + * **negate** - negation |
|
| 277 | + * **negify** - absolute negation |
|
| 278 | + * **sqrt** - square root |
|
| 279 | + |
|
| 280 | +With the exception of **abs**, **negate**, **negify**, and **sqrt**, all |
|
| 281 | +the tools require two inputs (known as a binary operator; note, this is |
|
| 282 | +**NOT** saying you need to enter binary numbers into them... they expect |
|
| 283 | +decimal values). The first input **MUST** come from STDIN. The second |
|
| 284 | +input **MUST** come from the first command-line argument. |
|
| 285 | + |
|
| 286 | +The tool, with the appropriate inputs, will perform the operation and |
|
| 287 | +output its result to STDOUT. |
|
| 288 | + |
|
| 289 | +The **abs**, **negate**, **negify**, and **sqrt** tools require only one |
|
| 290 | +input (known as a unary operator). That input **must** come from STDIN. |
|
| 291 | +When given an appropriate input, the operation is performed and will |
|
| 292 | +output its result to STDOUT. |
|
| 293 | + |
|
| 294 | +## PROCESS |
|
| 295 | + |
|
| 296 | +In the **TASK** file, you will be given a set of tasks you need to |
|
| 297 | +construct command-lines for to solve, using the tools provided to you in |
|
| 298 | +both the **numbers** and **pipemath** suites. You will also want to make |
|
| 299 | +use of pipes and command expansions in your solutions. |
|
| 300 | + |
|
| 301 | +There will also be result, numbers, operations, minimum pipes, and |
|
| 302 | +maximum pipes constraints listed for each problem, which you will need to |
|
| 303 | +abide by in order to receive full credit. |
|
| 304 | + |
|
| 305 | +The potential constraints are as follows: |
|
| 306 | + |
|
| 307 | + * **ANY:** no restrictions, any in applicable category can be used |
|
| 308 | + * **ONLY:** you are restricted to only those listed |
|
| 309 | + * **WITH_LIMITS:** usually providing specific restrictions within an **ANY** domain |
|
| 310 | + * **EXCEPT:** you are explicitly not allowed to use the listed; usually restricting an existing **ANY** domain |
|
| 311 | + |
|
| 312 | +There may also be quantity limits on how many times you can use each |
|
| 313 | +number or operation. If so, such will be shown in parenthesis following |
|
| 314 | +the item in question. |
|
| 315 | + |
|
| 316 | +Also, no cheating with idle "filler" operations, like "plus 0 | plus 0 | |
|
| 317 | +plus 0" to rack up needed pipe counts. |
|
| 318 | + |
|
| 319 | +As an example, take the following (formatted is it would appear in your |
|
| 320 | +**TASK** file): |
|
| 321 | + |
|
| 322 | +``` |
|
| 323 | +task: 0 |
|
| 324 | +result: 4 |
|
| 325 | +numbers: ONLY(three(2), five, seven, nine) |
|
| 326 | +operations: ANY |
|
| 327 | +min_pipes: 2 |
|
| 328 | +max_pipes: ANY |
|
| 329 | +``` |
|
| 330 | + |
|
| 331 | +With these in mind, we can set about solving this problem, using the |
|
| 332 | +tools in combination to arrive at the desired result. |
|
| 333 | + |
|
| 334 | +A potential solution would be as follows: |
|
| 335 | + |
|
| 336 | +``` |
|
| 337 | +yoursystem~:~/src/SEMESTER/unix/upf0$ seven | minus `three` |
|
| 338 | +4 |
|
| 339 | +yoursystem~:~/src/SEMESTER/unix/upf0$ |
|
| 340 | +``` |
|
| 341 | + |
|
| 342 | +BUT, we see that the **min_pipes** requirement is 2, and we only have 1 |
|
| 343 | +here... so we'll need to come up with another solution. |
|
| 344 | + |
|
| 345 | +How about: |
|
| 346 | + |
|
| 347 | +``` |
|
| 348 | +yoursystem~:~/src/SEMESTER/unix/upf0$ three | minus `seven` | negate |
|
| 349 | +4 |
|
| 350 | +yoursystem~:~/src/SEMESTER/unix/upf0$ |
|
| 351 | +``` |
|
| 352 | + |
|
| 353 | +There we go... still got our 4, but this time via the minimum required |
|
| 354 | +quantity of pipes. |
|
| 355 | + |
|
| 356 | +In this case, we'll want to record our command-line in the appropriate |
|
| 357 | +place. Since this is task #0, we'll want to record it in a file called: |
|
| 358 | +**task0.cli**, which should basically just contain the command-line you |
|
| 359 | +ran, merely placed in a text file. |
|
| 360 | + |
|
| 361 | +For example, if you **cat** the file, you should see the following: |
|
| 362 | + |
|
| 363 | +``` |
|
| 364 | +yoursystem~:~/src/SEMESTER/unix/upf0$ cat task0.cli |
|
| 365 | +three | minus `seven` | negate |
|
| 366 | +yoursystem~:~/src/SEMESTER/unix/upf0$ |
|
| 367 | +``` |
|
| 368 | + |
|
| 369 | +Basically, each task#.cli can be its own script. If we were to execute |
|
| 370 | +it, the correct result should be produced. |
|
| 371 | + |
|
| 372 | +## UPF0STEPS |
|
| 373 | + |
|
| 374 | +You will once again be creating a steps file that can automate your |
|
| 375 | +project. |
|
| 376 | + |
|
| 377 | +As in previous projects, **upf0steps** will contain the steps you took |
|
| 378 | +from the point of downloading the pipemath suite up until the submit step |
|
| 379 | +(hint: just run the task#.cli scripts within the steps script). |
|
| 380 | + |
|
| 381 | +To clarify: YES, downloading files in question, extracting, compiling, |
|
| 382 | +installing, and then of course running each individual task#.cli script. |
|
| 383 | + |
|
| 384 | +There are some additional constraints you need to keep in mind: |
|
| 385 | + |
|
| 386 | + * your script should not produce ANY STDERR output |
|
| 387 | + * your script should ONLY produce STDOUT output in conformance with the below stated requirements. Any other output needs to be silenced. |
|
| 388 | + * For each task, you'll want to display things as follows: |
|
| 389 | + * "Task X result is: #" |
|
| 390 | + * where X is the task number (0, 1, 2, etc.) |
|
| 391 | + * where # is the calculated output matching the TASK file result requested (ie, you must run your task#.cli script to produce this output). |
|
| 392 | + * note that the task#.cli output appears on the SAME line as the "Task X result is:" text, and there is a single space separating it from the colon. |
|
| 393 | + * additionally, your upf0steps file will only create, alter files if run by you. If run by a user who is not you, skip the file manipulation and only output the results. |
|
| 394 | + * you will be making use of a loop to drive the execution of your results (the "Task # result is: ..."). |
|
| 395 | + |
|
| 396 | +For example, a sample output of your **upf0steps** script should appear |
|
| 397 | +like follows (but your # values will of course be different based on your |
|
| 398 | +individual **TASK** file): |
|
| 399 | + |
|
| 400 | +``` |
|
| 401 | +yoursystem~:~/src/SEMESTER/unix/upf0$ ./upf0steps |
|
| 402 | +Task 0 result is: 13 |
|
| 403 | +Task 1 result is: 27 |
|
| 404 | +Task 2 result is: 32 |
|
| 405 | +Task 3 result is: 7 |
|
| 406 | +Task 4 result is: -4 |
|
| 407 | +Task 5 result is: 57 |
|
| 408 | +Task 6 result is: 2 |
|
| 409 | +Task 7 result is: 98 |
|
| 410 | +yoursystem~:~/src/SEMESTER/unix/upf0$ |
|
| 411 | +``` |
|
| 412 | + |
|
| 413 | +## SUBMISSION |
|
| 414 | + |
|
| 415 | +By successfully performing this project, you should have a set of |
|
| 416 | +`task#.cli` files (one for each task). You will want to submit these, |
|
| 417 | +along with a **upf0steps** file. |
|
| 418 | + |
|
| 419 | +### SUBMIT TOOL USAGE |
|
| 420 | + |
|
| 421 | +To submit this project to me using the **submit** tool, run the following |
|
| 422 | +command at your lab46 prompt: |
|
| 423 | + |
|
| 424 | +``` |
|
| 425 | +lab46:~/src/SEMESTER/unix/upf0$ submit unix upf0 upf0steps task*.cli |
|
| 426 | +Submitting unix project "upf0": |
|
| 427 | + -> upf0steps(OK) |
|
| 428 | + -> task0.cli(OK) |
|
| 429 | + -> task1.cli(OK) |
|
| 430 | + -> task2.cli(OK) |
|
| 431 | + -> task3.cli(OK) |
|
| 432 | + ... |
|
| 433 | + |
|
| 434 | +SUCCESSFULLY SUBMITTED |
|
| 435 | +``` |
|
| 436 | + |
|
| 437 | +You should get some sort of confirmation indicating successful submission |
|
| 438 | +if all went according to plan. If not, check for typos and or locational |
|
| 439 | +mismatches. |
|
| 440 | + |
|
| 441 | +### RUBRIC |
|
| 442 | + |
|
| 443 | +I'll be looking for the following: |
|
| 444 | + |
|
| 445 | +``` |
|
| 446 | +182:upf0:final tally of results (182/182) |
|
| 447 | +*:upf0:upf0steps has valid list of non-interactive instructions [26/26] |
|
| 448 | +*:upf0:upf0steps only modifies files if USER matches [26/26] |
|
| 449 | +*:upf0:upf0steps obtains, builds latest pipemath release [26/26] |
|
| 450 | +*:upf0:upf0steps only displays specified STDOUT output [13/13] |
|
| 451 | +*:upf0:upf0steps uses command expansions to get information [26/26] |
|
| 452 | +*:upf0:upf0steps uses a loop to drive numbers in final output [26/26] |
|
| 453 | +*:upf0:all files are organized, clear, and easy to read [13/13] |
|
| 454 | +*:upf0:task#.cli files have solution within given constraints [13/13] |
|
| 455 | +*:upf0:files tracked in private semester repository [13/13] |
|
| 456 | +``` |
|
| 457 | + |
|
| 458 | +Additionally: |
|
| 459 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 460 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 461 | + * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction |
|
| 462 | + * Solutions not organized and easy to read are subject to a 25% overall deduction |
haas/fall2026/unix/projects/usr0.md
| ... | ... | @@ -0,0 +1,305 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: UNIX SKILLS REVIEW (usr0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +To practice/review some previously utilized skills in order to obtain |
|
| 8 | +better mastery (assuming you've done the reading and successfully |
|
| 9 | +completed prior encounters with this topic), in combination with a |
|
| 10 | +specific focus on time management. |
|
| 11 | + |
|
| 12 | +It has been a while since we first encountered file permissions; yet they |
|
| 13 | +constantly remain ready to be put to use in our problem solving |
|
| 14 | +endeavours. I figure it would be a good time to have you review that |
|
| 15 | +concept, so this is a project dedicated to that, along with exploring |
|
| 16 | +them in further depth (and, well, time management). |
|
| 17 | + |
|
| 18 | +## REFERENCE |
|
| 19 | + |
|
| 20 | +Be sure you are familiar with the octal file permissions, as are used |
|
| 21 | +with the **chmod** command. You might want to check out: |
|
| 22 | + |
|
| 23 | + * **chmod**(**1**) |
|
| 24 | + * **chmod**(**2**) |
|
| 25 | + |
|
| 26 | +## REVIEW TOPIC |
|
| 27 | + |
|
| 28 | +For this week, the main topic of review will be file permissions. We see |
|
| 29 | +them when running an **ls -l**, for example: |
|
| 30 | + |
|
| 31 | +``` |
|
| 32 | +lab46:/usr/local/bin$ ls -l s[uta]* |
|
| 33 | +-rwxr-xr-x 1 root staff 3126 Oct 3 2023 /usr/local/bin/sanitizehg |
|
| 34 | +-rwx------ 1 root staff 3646 Feb 25 2021 /usr/local/bin/sanitizewebfiles |
|
| 35 | +-rwxr-x--- 1 wedge lab46 763 Nov 19 2024 /usr/local/bin/status |
|
| 36 | +-rwxr-x--- 1 wedge lab46 11002 Apr 21 2022 /usr/local/bin/status.logic |
|
| 37 | +-rwxr-x--- 1 wedge lab46 16974 Mar 31 2024 /usr/local/bin/submit |
|
| 38 | +-rwxr-x--- 1 wedge lab46 7108 Oct 29 2021 /usr/local/bin/submitchk |
|
| 39 | +lab46:/usr/local/bin$ |
|
| 40 | +``` |
|
| 41 | + |
|
| 42 | +Of course, the file permission part is: |
|
| 43 | + |
|
| 44 | +``` |
|
| 45 | + -rwxr-x--- |
|
| 46 | +``` |
|
| 47 | + |
|
| 48 | +We split this into 3 fields (the leftmost dash is an additional field, |
|
| 49 | +and is for the file type) into user, group, and other. |
|
| 50 | + |
|
| 51 | + * `-` indicates a regular file (not part of the file permission scheme) |
|
| 52 | + * `rwx` corresponds to the user permissions |
|
| 53 | + * `r-x` corresponds to the group permissions |
|
| 54 | + * `---` corresponds to those who are neither the user nor the group |
|
| 55 | + |
|
| 56 | +Breakdown is as follows: |
|
| 57 | + |
|
| 58 | + * read `(r)` is 4 |
|
| 59 | + * write `(w)` is 2 |
|
| 60 | + * execute/search `(x)` is 1 |
|
| 61 | + * nothing `(-)` is 0 |
|
| 62 | + |
|
| 63 | +In any given field, we add up the values, which will result in a value |
|
| 64 | +within the range 0-7. |
|
| 65 | + |
|
| 66 | +So, in our example above, broken down showing the component permissions: |
|
| 67 | + |
|
| 68 | + |
|
| 69 | +``` |
|
| 70 | + u g o |
|
| 71 | + - rwx r-x --- |
|
| 72 | + 7 5 0 |
|
| 73 | +``` |
|
| 74 | + |
|
| 75 | +Practice: Come up with the file permissions for all the files listed in |
|
| 76 | +the example above. See how you fare. |
|
| 77 | + |
|
| 78 | +I wrote a tool for you to use in this project; it is called **urev**. It |
|
| 79 | +is located on and run on lab46. |
|
| 80 | + |
|
| 81 | +Your task will be to run this and complete a minimum of 144 problems |
|
| 82 | +(you'll be able to do a maximum of 192-- and those that do more than 144 |
|
| 83 | +may see some benefit), in groups of 12 at a time (so you don't blow |
|
| 84 | +through them all in one sitting.. there's also a time delay before you |
|
| 85 | +can do the next set of 12-- so you clearly shouldn't wait until the last |
|
| 86 | +minute). |
|
| 87 | + |
|
| 88 | +To use **urev**, basically type in the 3 or 4 octal values matching the |
|
| 89 | +problem displayed (in the above example, you'd type in '7' '5' and '0', |
|
| 90 | +and upon input of each value, it will appear on the screen. |
|
| 91 | + |
|
| 92 | +If you get all 3 (or 4) correct, you'll earn a point. (Careful not to |
|
| 93 | +type too fast, otherwise the output may appear garbled). |
|
| 94 | + |
|
| 95 | +Any accumulated mistakes can be mitigated by doing problems in excess of |
|
| 96 | +the 144 required minimum. Once any mistakes have been nullified, some |
|
| 97 | +apportionment of bonus points can then be attained (not to exceed half |
|
| 98 | +the total points the project is worth). |
|
| 99 | + |
|
| 100 | +### PRACTICE PROBLEMS |
|
| 101 | + |
|
| 102 | +``` |
|
| 103 | +- rwx r-x r-x /usr/local/bin/sanitizehg (755) |
|
| 104 | +- rwx --- --- /usr/local/bin/sanitizewebfiles (700) |
|
| 105 | +- rwx r-x --- /usr/local/bin/status (750) |
|
| 106 | +- rwx r-x --- /usr/local/bin/status.logic (750) |
|
| 107 | +- rwx r-x --- /usr/local/bin/submit (750) |
|
| 108 | +- rwx r-x --- /usr/local/bin/submitchk (750) |
|
| 109 | +``` |
|
| 110 | + |
|
| 111 | +## 4TH TIER PERMISSIONS |
|
| 112 | + |
|
| 113 | +In addition to the classic three-valued permissions, there is an |
|
| 114 | +additional tier of permissions, corresponding to the "SetUID", "SetGID", |
|
| 115 | +and "Sticky Bit" modes. These represent a fourth value (the leading |
|
| 116 | +value). |
|
| 117 | + |
|
| 118 | +**Be aware:** Once you reach your 96th problem, this mode will be |
|
| 119 | +unlocked, and all modes entered will be 4-octal values long. |
|
| 120 | + |
|
| 121 | +To maintain general compatibility with the existing structure of the |
|
| 122 | +system, especially organization and real estate taken up by the display |
|
| 123 | +of the unix filemode string, this further tier of permissions instead |
|
| 124 | +overlays atop the 'x' fields of the user, group, and other fields. |
|
| 125 | + |
|
| 126 | +Breakdown is as follows: |
|
| 127 | + |
|
| 128 | + * SetUID `(s)` has a value of 4 |
|
| 129 | + * this will manifest in the user field, overlaying its 'x' bit position |
|
| 130 | + * 's' if 'x' is present, 'S' if 'x' is not present |
|
| 131 | + * SetGID `(s)` has a value of 2 |
|
| 132 | + * this will manifest in the group field, overlaying its 'x' bit position |
|
| 133 | + * 's' if 'x' is present, 'S' if 'x' is not present |
|
| 134 | + * the Sticky Bit `(t)` has a value of 1 |
|
| 135 | + * this will manifest in the other field, overlaying its 'x' bit position |
|
| 136 | + * 't' if 'x' is present, 'T' if 'x' is not present |
|
| 137 | + * nothing `(-)` is 0 |
|
| 138 | + |
|
| 139 | +``` |
|
| 140 | +lab46:/usr/bin$ ls -l at procmail su |
|
| 141 | +-rwsr-sr-x 1 daemon daemon 59768 Oct 15 2022 /usr/bin/at |
|
| 142 | +-rwsr-sr-x 1 root mail 101664 Mar 1 2022 /usr/bin/procmail |
|
| 143 | +-rwsr-xr-x 1 root root 72000 Nov 21 2024 /usr/bin/su |
|
| 144 | +lab46:/usr/bin$ |
|
| 145 | +``` |
|
| 146 | + |
|
| 147 | +Of course, the file permission part is: |
|
| 148 | + |
|
| 149 | +``` |
|
| 150 | + -rwsr-sr-x |
|
| 151 | +``` |
|
| 152 | + |
|
| 153 | +We split this into 3 fields (the leftmost dash is an additional field, |
|
| 154 | +and is for the file type) into user, group, and other. |
|
| 155 | + |
|
| 156 | + * `-` indicates a regular file (not part of the file permission scheme) |
|
| 157 | + * `rws` corresponds to the user permissions |
|
| 158 | + * `r-s` corresponds to the group permissions |
|
| 159 | + * `r-x` corresponds to those who are neither the user nor are in the group |
|
| 160 | + |
|
| 161 | +In any given field, we add up the values, which will result in a value |
|
| 162 | +within the range 0-7. The same is the case here. |
|
| 163 | + |
|
| 164 | +We start by computing the new, topmost tier: |
|
| 165 | + |
|
| 166 | + * Is there an 's' or 'S' in the user field? If so: 4. If not: 0. |
|
| 167 | + * Is there an 's' or 'S' in the group field? If so: 2. If not: 0. |
|
| 168 | + * Is there a 't' or 'T' in the other field? If so: 1. If not: 0. |
|
| 169 | + |
|
| 170 | +Breakdown is as follows: |
|
| 171 | + |
|
| 172 | + * user has an 's', so: 4 |
|
| 173 | + * group has a 's', so: 2 |
|
| 174 | + * other does not have a 't', so: 0 |
|
| 175 | + |
|
| 176 | +Add them up: 4+2+0=6. That is our first value. |
|
| 177 | + |
|
| 178 | +We then proceed to process the remaining 3 tiers as before: |
|
| 179 | + |
|
| 180 | + * user is 'rwx' (lowercase 's' indicates an 'x' underneath), for a: 7 |
|
| 181 | + * group is 'r-x' (lowercase 's' indicates an 'x' underneath), for a: 5 |
|
| 182 | + * other is 'r-x' (if there were a lowercase 't', it would indicate an 'x' underneath), for a: 5 |
|
| 183 | + |
|
| 184 | +Final 4-tier octal permission for the example is therefore: 6755. |
|
| 185 | + |
|
| 186 | +Practice with the other examples, compare your results and see how you |
|
| 187 | +fare. |
|
| 188 | + |
|
| 189 | +You are to calculate this tier of permissions separate from the others |
|
| 190 | +(it is a distinct, separate fourth octal value, leading the classic |
|
| 191 | +three-valued permissions you've been working on so far). |
|
| 192 | + |
|
| 193 | +Over time, there may be changes in display form and difficulty. Think it |
|
| 194 | +through, answer with confidence! |
|
| 195 | + |
|
| 196 | +### PRACTICE |
|
| 197 | + |
|
| 198 | +``` |
|
| 199 | +-rwsr-sr-x /usr/bin/at (6755) |
|
| 200 | +-rwsr-sr-x /usr/bin/procmail (6755) |
|
| 201 | +-rwsr-xr-x /usr/bin/su (4755) |
|
| 202 | +``` |
|
| 203 | + |
|
| 204 | +## TIME DELAY |
|
| 205 | + |
|
| 206 | +To reinforce mastery, there is a time delay instituted to prevent |
|
| 207 | +accomplishing this task in one sitting. You will have to plan your time |
|
| 208 | +accordingly to perform this project in the time allotted. |
|
| 209 | + |
|
| 210 | +### PROJECT STATS |
|
| 211 | + |
|
| 212 | +A general overview of how the class has approached the project: |
|
| 213 | + |
|
| 214 | + |
|
| 215 | + |
|
| 216 | +where each color represents one individual's activity that day, stacked |
|
| 217 | +with that of others, enabling an overall per day general class activity. |
|
| 218 | +Higher bars and larger chunks of bars denote greater activity. |
|
| 219 | + |
|
| 220 | +And a more individual effort: |
|
| 221 | + |
|
| 222 | + |
|
| 223 | + |
|
| 224 | +where each line is an individual's cumulative progress over the set of |
|
| 225 | +days the project is available. The higher the line, the more work is |
|
| 226 | +being done. |
|
| 227 | + |
|
| 228 | +## HISTORICAL PROJECT RESULTS |
|
| 229 | + |
|
| 230 | +### FALL2025 |
|
| 231 | + |
|
| 232 | +General: |
|
| 233 | + |
|
| 234 | + |
|
| 235 | +Individual: |
|
| 236 | + |
|
| 237 | + |
|
| 238 | +### SPRING2025 |
|
| 239 | + |
|
| 240 | +General: |
|
| 241 | + |
|
| 242 | + |
|
| 243 | +Individual: |
|
| 244 | + |
|
| 245 | + |
|
| 246 | +### FALL2024 |
|
| 247 | + |
|
| 248 | +General: |
|
| 249 | + |
|
| 250 | + |
|
| 251 | +Individual: |
|
| 252 | + |
|
| 253 | + |
|
| 254 | +### SPRING2024 |
|
| 255 | + |
|
| 256 | +General: |
|
| 257 | + |
|
| 258 | + |
|
| 259 | +Individual: |
|
| 260 | + |
|
| 261 | + |
|
| 262 | +### FALL2023 |
|
| 263 | + |
|
| 264 | +General: |
|
| 265 | + |
|
| 266 | + |
|
| 267 | +Individual: |
|
| 268 | + |
|
| 269 | + |
|
| 270 | +### SPRING2023 |
|
| 271 | + |
|
| 272 | +General: |
|
| 273 | + |
|
| 274 | + |
|
| 275 | +Individual: |
|
| 276 | + |
|
| 277 | + |
|
| 278 | +## SUBMISSION |
|
| 279 | + |
|
| 280 | +Submission for this project is super-easy: simply complete the minimum |
|
| 281 | +required problems (144) by the deadline; no need to manually submit |
|
| 282 | +anything- just doing your **urev** allotments on lab46 is all that needs |
|
| 283 | +to be done. |
|
| 284 | + |
|
| 285 | +There is an opportunity to gain bonus points, and/or make up for mistakes |
|
| 286 | +made during the performing of this project, by doing more problems in |
|
| 287 | +addition to the 144 minimum. |
|
| 288 | + |
|
| 289 | +A central focus of this project is an enforced time management. You may |
|
| 290 | +want to plan ahead to make sure you budget the adequate time so you do |
|
| 291 | +not end up missing out. |
|
| 292 | + |
|
| 293 | +### RUBRIC |
|
| 294 | + |
|
| 295 | +I'll be evaluating the project based on the following criteria: |
|
| 296 | + |
|
| 297 | +``` |
|
| 298 | +208:usr0:final tally of results (208/208) |
|
| 299 | +*:usr0:completed required 3-tier problems successfully [104/104] |
|
| 300 | +*:usr0:completed required 4-tier problems successfully [104/104] |
|
| 301 | +``` |
|
| 302 | + |
|
| 303 | +**NOTE:** as with other projects, in order to get credit for the project |
|
| 304 | +it must be submitted. To submit this project, you must have completed 144 |
|
| 305 | +problems. Not doing so will not garner you any points. |
haas/fall2026/unix/projects/wpa0.md
| ... | ... | @@ -0,0 +1,217 @@ |
| 1 | +# CSCS1730 UNIX/Linux Fundamentals |
|
| 2 | + |
|
| 3 | +# PROJECT: WEB PAGE ADVENTURE (wpa0) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +One of the original draws of the early World Wide Web, which for most |
|
| 8 | +people seems to have outpaced the general Internet in popularity, was the |
|
| 9 | +ability to host web pages. |
|
| 10 | + |
|
| 11 | +We will be experiencing that very task, through the manual creation of |
|
| 12 | +our own web pages, as well as the necessary UNIX-related backdrop helping |
|
| 13 | +to ensure its operation. |
|
| 14 | + |
|
| 15 | +## URL |
|
| 16 | + |
|
| 17 | +Web pages are written in HTML (HyperText Markup Language), a document |
|
| 18 | +format that web browsers can interpret and render content to the screen. |
|
| 19 | + |
|
| 20 | +They are reached via URLs (Uniform Resource Locators), which inform |
|
| 21 | +various tools of the how, where, and what to retrieve. |
|
| 22 | + |
|
| 23 | +How: what is known as a schema, this is the `http://`, `https://`, and |
|
| 24 | +`ftp://` that far too often is abstracted by the web browser in the |
|
| 25 | +address bar. This doesn't mean it is by any means optional: the web |
|
| 26 | +browser still has to insert that information. |
|
| 27 | + |
|
| 28 | +Where: host, fully-qualified domain name (FQDN), and any resultant path |
|
| 29 | +referencing the location of content on the server |
|
| 30 | + |
|
| 31 | +What: the actual file we wish to retrieve. Often times, if no specific |
|
| 32 | +file is requested, the web server can be configured to serve a default |
|
| 33 | +"**index.html**". |
|
| 34 | + |
|
| 35 | +In our case, we'll be using the Lab46 Web Server to host our own web |
|
| 36 | +content. Piecing together the above how, where, and what, our URL will |
|
| 37 | +resemble the following: |
|
| 38 | + |
|
| 39 | + * https://lab46.g7n.org/~username/wpa0/adventure.html |
|
| 40 | + |
|
| 41 | +Many of you have likely already been interacting with your web URL as a |
|
| 42 | +means of facilitating activities in other assignments. |
|
| 43 | + |
|
| 44 | +The "**~username**", and specifically the tilde (~), is a |
|
| 45 | +server-configured feature indicating your home directory's web directory, |
|
| 46 | +which is **public_html/**, any content put under that directory and made |
|
| 47 | +world readable (**public_html/** itself as well as your parent home |
|
| 48 | +directory must both have world search (aka execute) in order for it to |
|
| 49 | +work as well). You may create subdirectories under **public_html/** and |
|
| 50 | +store web content under them- the same permissions requirements apply. |
|
| 51 | + |
|
| 52 | +In some web-server contexts, your **public_html/** directory might also |
|
| 53 | +be referred to as a sort of "document root". So if you see paths starting |
|
| 54 | +with "/", that does NOT mean the root of the filesystem, but the base of |
|
| 55 | +your **public_html/** directory. |
|
| 56 | + |
|
| 57 | +To reference any subdirectories, merely append the directory name after |
|
| 58 | +the "**~username/**" component of the URL. |
|
| 59 | + |
|
| 60 | +Basic rule of thumb for file permissions is as follows: |
|
| 61 | + |
|
| 62 | + * web pages and image assets need to be world readable |
|
| 63 | + * directories (all directories from the home directory through directory containing your content) need to be world searchable |
|
| 64 | + |
|
| 65 | +## HTML |
|
| 66 | + |
|
| 67 | +As indicated above, web documents intended for viewing in a web browser |
|
| 68 | +are predominantly either written (or ultimately displayed as) HTML. |
|
| 69 | + |
|
| 70 | +HTML uses a set of predefined tags, and a google search for HTML tags |
|
| 71 | +will turn up a seemingly unending list of information on HTML and the |
|
| 72 | +available tags, that information which you will be required to obtain to |
|
| 73 | +complete this project. |
|
| 74 | + |
|
| 75 | +The basic format of many tags is of one of the two formats: |
|
| 76 | + |
|
| 77 | + * pair (open and close): `<p>This identifies a paragraph</p>` |
|
| 78 | + * unary (standalone): `<img src="images/image1.png" />` |
|
| 79 | + |
|
| 80 | +The forward slash (stroke) is used to identify the closing tag, and is |
|
| 81 | +also present at the end of the unary tag. |
|
| 82 | + |
|
| 83 | +Common mistakes are misspelling the tag, or forgetting to close an |
|
| 84 | +opening tag. |
|
| 85 | + |
|
| 86 | +## TASK |
|
| 87 | + |
|
| 88 | +Your task for this project will be to create a series of web pages in the |
|
| 89 | +form of a simple web-based adventure game. |
|
| 90 | + |
|
| 91 | +It will consist of a minimum of 11 pages (1 for start page, 1 for map |
|
| 92 | +page, 9 minimum for world pages-- of course, you can **always** have |
|
| 93 | +more), each one consisting of a room that the viewer can navigate to. |
|
| 94 | + |
|
| 95 | +You get to come up with the theme of your particular world/adventure. Is |
|
| 96 | +it medieval? Futuristic? Based in the Thundercats universe? Filled with |
|
| 97 | +furries? Bronies? Pick something you can have fun with that still |
|
| 98 | +conforms to the requirements. |
|
| 99 | + |
|
| 100 | +Requirements are as follows: |
|
| 101 | + |
|
| 102 | + * all pages and resources are referenced relatively. Nothing should be hardcoded to any host or location. This will allow one to relocate your website to a different location and have it still work with no changes. |
|
| 103 | + * all web site assets are to be stored locally. No external references. |
|
| 104 | + * overall website size should not exceed 12MB. |
|
| 105 | + * starting page in the base of your **public_html/wpa0/** directory with a file named: **adventure.html** |
|
| 106 | + * This page should have an introduction describing the nature of your quest/adventure |
|
| 107 | + * also in the base you should have a **map.html** file which describes the world you've created |
|
| 108 | + * it should provide a "map" allowing a viewer to successfully make it through to the goal and avoid any obstacles |
|
| 109 | + * at least 9 additional pages making up your web-based adventure |
|
| 110 | + * each page must have a set of links to adjoining rooms (methods of connection up to you: left, right, up, down, north, south, etc.) and clicking on the link takes you to that adjoining page |
|
| 111 | + * there needs to be a logical connection of your rooms, so that there can exist a path or paths to enable the viewer to navigate from start to completion |
|
| 112 | + * you need to have (at least) 3 obstacles of some sort (unending abyss, space aliens abduct you, a hungry grue, or whatever fits the overall theme of your adventure). These can constitute dead ends (and if terminal dead ends, should only provide a link back to "start over"). |
|
| 113 | + * each page representing a room in your world needs to have (at minimum): |
|
| 114 | + * links to adjoining rooms (even if a terminal dead end- something to let the user "start over") |
|
| 115 | + * descriptions of what the viewer encounters in each room, providing a narrative enticing the user to continue on this adventure you've crafted for them |
|
| 116 | + * each "room" page needs to be in its own subdirectory beneath **public_html/wpa0/**, and any associated media files located in that same directory. At the very least, you must have a minimum of 3 subdirectories upon which your adventure is organized and correctly references content amongst |
|
| 117 | + * you need to have at least 4 images scattered throughout your world. These can be in the form of a visual aid, augmenting any textual description found on a given page |
|
| 118 | + * You must make use of the following: |
|
| 119 | + * text bolding |
|
| 120 | + * paragraphs |
|
| 121 | + * list |
|
| 122 | + * images |
|
| 123 | + * links |
|
| 124 | + * underline or italics |
|
| 125 | + * table |
|
| 126 | + * font color or size change |
|
| 127 | + |
|
| 128 | +As this would be a great opportunity to better familiarize yourself with |
|
| 129 | +**vi/vim**, I will emphasize the following: |
|
| 130 | + |
|
| 131 | + * I want you to create these files locally on lab46, using **vim**. |
|
| 132 | + * This activity is more a focus on your file manipulation skills in the UNIX environment than a display of your web authoring skills. |
|
| 133 | + * Not only am I not expecting anyone to have any prior web authoring experience, but I am interested in seeing how those with experience "cope" with a lack of any preferred "shiny" authoring tools. |
|
| 134 | + * Again, this isn't an endeavor to see how polished a site you can make, but instead how you deal with the remote and administrative aspects of web design (which frequently finds one interacting with UNIX systems). |
|
| 135 | + |
|
| 136 | +## CURRENT SEMESTER ENDEAVOURS |
|
| 137 | + |
|
| 138 | +Here are the starting pages for the efforts this semester: |
|
| 139 | + |
|
| 140 | + * [https://lab46.g7n.org/~cg004474/wpa0/adventure.html](https://lab46.g7n.org/~cg004474/wpa0/adventure.html) |
|
| 141 | + * [https://lab46.g7n.org/~ebaile11/wpa0/adventure.html](https://lab46.g7n.org/~ebaile11/wpa0/adventure.html) |
|
| 142 | + * [https://lab46.g7n.org/~lbailey6/wpa0/adventure.html](https://lab46.g7n.org/~lbailey6/wpa0/adventure.html) |
|
| 143 | + * [https://lab46.g7n.org/~lwyrick/wpa0/adventure.html](https://lab46.g7n.org/~lwyrick/wpa0/adventure.html) |
|
| 144 | + * [https://lab46.g7n.org/~qlewis/wpa0/adventure.html](https://lab46.g7n.org/~qlewis/wpa0/adventure.html) |
|
| 145 | + |
|
| 146 | +## PAST ENTRIES |
|
| 147 | + |
|
| 148 | +Here are some prior semester examples, which you can use for inspiration |
|
| 149 | +(but please, no wholesale copying!) |
|
| 150 | + |
|
| 151 | + * [https://lab46.g7n.org/~wedge/wpa0/abarbcal/adventure.html](https://lab46.g7n.org/~wedge/wpa0/abarbcal/adventure.html) |
|
| 152 | + * [https://lab46.g7n.org/~bpatrice/wpa0/adventure.html](https://lab46.g7n.org/~bpatrice/wpa0/adventure.html) |
|
| 153 | + * [https://lab46.g7n.org/~eraffer2/wpa0/adventure.html](https://lab46.g7n.org/~eraffer2/wpa0/adventure.html) |
|
| 154 | + * [https://lab46.g7n.org/~wedge/wpa0/pgrant3/adventure.html](https://lab46.g7n.org/~wedge/wpa0/pgrant3/adventure.html) |
|
| 155 | + * [https://lab46.g7n.org/~wedge/wpa0/zswartwo/adventure.html](https://lab46.g7n.org/~wedge/wpa0/zswartwo/adventure.html) |
|
| 156 | + * [https://lab46.g7n.org/~wedge/wpa0/nburns/adventure.html](https://lab46.g7n.org/~wedge/wpa0/nburns/adventure.html) |
|
| 157 | + * [https://lab46.g7n.org/~memeryjr/wpa0/adventure.html](https://lab46.g7n.org/~memeryjr/wpa0/adventure.html) |
|
| 158 | + * [https://lab46.g7n.org/~ngugliel/wpa0/adventure.html](https://lab46.g7n.org/~ngugliel/wpa0/adventure.html) |
|
| 159 | + * [https://lab46.g7n.org/~wedge/wpa0/gsuber/adventure.html](https://lab46.g7n.org/~wedge/wpa0/gsuber/adventure.html) |
|
| 160 | + * [https://lab46.g7n.org/~kjacks19/wpa0/adventure.html](https://lab46.g7n.org/~kjacks19/wpa0/adventure.html) |
|
| 161 | + * [https://lab46.g7n.org/~wedge/wpa0/mfee1/adventure.html](https://lab46.g7n.org/~wedge/wpa0/mfee1/adventure.html) |
|
| 162 | + * [https://lab46.g7n.org/~wedge/wpa0/rsanche1/adventure.html](https://lab46.g7n.org/~wedge/wpa0/rsanche1/adventure.html) |
|
| 163 | + * [https://lab46.g7n.org/~wedge/wpa0/hcordell/adventure.html](https://lab46.g7n.org/~wedge/wpa0/hcordell/adventure.html) |
|
| 164 | + * [https://lab46.g7n.org/~amelvil2/0x2/adventure.html](https://lab46.g7n.org/~amelvil2/0x2/adventure.html) |
|
| 165 | + * [https://lab46.g7n.org/~gsalce/0x1/adventure.html](https://lab46.g7n.org/~gsalce/0x1/adventure.html) |
|
| 166 | + |
|
| 167 | +## SUBMISSION |
|
| 168 | + |
|
| 169 | +To successfully complete this project, the following criteria must be met: |
|
| 170 | + |
|
| 171 | + * All criteria indicated above |
|
| 172 | + * To signal completion, submit the following to me: |
|
| 173 | + * URL of your starting page in your lab46 web space. |
|
| 174 | + * gzipped tar archive of your entire web page adventure content (including images, all in their respective subdirectories based off **~/public_html/wpa0/** as the base directory). |
|
| 175 | + * archive must preserve your original permissions. |
|
| 176 | + |
|
| 177 | +To submit this project to me using the **submit** tool, run the following |
|
| 178 | +command at your lab46 prompt: |
|
| 179 | + |
|
| 180 | +``` |
|
| 181 | +lab46:~/src/SEMESTER/unix/wpa0$ submit unix wpa0 wpa0.tar.gz https://lab46.g7n.org/~username/adventure.html |
|
| 182 | +Submitting unix project "wpa0": |
|
| 183 | + -> wpa0.tar.gz (OK) |
|
| 184 | + -> https://lab46.g7n.org/~username/adventure.html(OK) |
|
| 185 | + |
|
| 186 | +SUCCESSFULLY SUBMITTED |
|
| 187 | +``` |
|
| 188 | + |
|
| 189 | +You should get some sort of confirmation indicating successful submission |
|
| 190 | +if all went according to plan. If not, check for typos or location |
|
| 191 | +mismatches. |
|
| 192 | + |
|
| 193 | +### RUBRIC |
|
| 194 | + |
|
| 195 | +I'll be evaluating the project based on the following criteria: |
|
| 196 | + |
|
| 197 | +``` |
|
| 198 | +234:wpa0:final tally of results (234/234) |
|
| 199 | +*:wpa0:only relative addressing used [13/13] |
|
| 200 | +*:wpa0:all assets hosted locally on lab46 [13/13] |
|
| 201 | +*:wpa0:overall website is under 12MiB in size [13/13] |
|
| 202 | +*:wpa0:successfully submitted project [13/13] |
|
| 203 | +*:wpa0:correct URL given [13/13] |
|
| 204 | +*:wpa0:has starting page at /adventure.{html,php} [13/13] |
|
| 205 | +*:wpa0:adventure starting page describes adventure [13/13] |
|
| 206 | +*:wpa0:adventure page has link(s) to navigate [13/13] |
|
| 207 | +*:wpa0:has map page at /map.{html,php} [13/13] |
|
| 208 | +*:wpa0:at least 9 additional pages [13/13] |
|
| 209 | +*:wpa0:each additional page has link(s) to navigate [13/13] |
|
| 210 | +*:wpa0:each additional page is connected via available links [13/13] |
|
| 211 | +*:wpa0:adventure contains at least 4 images [13/13] |
|
| 212 | +*:wpa0:adventure pages utilize additional content enhancements [13/13] |
|
| 213 | +*:wpa0:minimum of three subdirectories storing adventure files [13/13] |
|
| 214 | +*:wpa0:page and media located in pertinent directory [13/13] |
|
| 215 | +*:wpa0:web site also stored in private semester repository [13/13] |
|
| 216 | +*:wpa0:web site visitations solicited on the DISCORD for feedback [13/13] |
|
| 217 | +``` |