Differences

This shows you the differences between two versions of the page.

--- haas:fall2022:cprog:projects:dow0 [2021/03/22 14:47] – created - external edit 127.0.0.1
+++ haas:fall2022:cprog:projects:dow0 [2022/09/23 21:26] (current) – [RUBRIC] wedge
@@ Line 4: / Line 4: @@
 </WRAP>
-======Project: MENTAL MATH - DAY OF WEEK (DOW0)======
+======PROJECT: MENTAL MATH - DAY OF WEEK (DOW0)======
-=====Objective=====
+=====OBJECTIVE=====
-To implement a programmatic solution (ie simulation) of a real life process- the mental math trick of determining what day of the week January 1 of any given year (in the 21st century) falls on.
+To begin our exploration of programming, starting with an investigation into the various data types available in C, along with their properties, and collaboratively authoring and documenting the project and its specifications.
-======Assumptions======
+=====GRABIT=====
+To assist with consistency across all implementations, data files for use with this project are available on lab46 via the **grabit** tool. Be sure to obtain it and ensure your implementation properly works with the provided data.
-To assist you in completing this project, you may make the following assumptions:
-  * all requests will be for days in the 21st century (2000-2099)
-=====Prerequisites/Corequisites=====
-In addition to the new skills required on previous projects, to successfully accomplish/perform this project, the listed resources/experiences need to be consulted/achieved:
-  * ability to construct and use selection statements (if)
-  * ability to distinguish between integer types and floating point types
-=====Background=====
-Mental Math constitutes an intersection of mental tricks and math- instead of utilizing a purely math-only solution, textual manipulations or simplifications in the computational process may take place enabling an individual to, once having learned the process, solve such problems in their head, and typically without the use of a calculating device.
-The process in this case is one of simple (reduced) multiplication and mapping against a table. To wit:
-====Day values====
-For this trick to work, we need to be familiar with the following table (a map of days to numeric values):
-^  Monday  ^  Tuesday  ^  Wednesday  ^  Thursday  ^  Friday  ^  Saturday  ^  Sunday  |
-|  1  |  2  |  3  |  4  |  5  |  6  |  7 or 0  |
-**NOTE:** Depending on how you implement your algorithm, you may find your approach prefers 7s OR 0s... you aren't necessarily going to be encountering them at random. Once you work through your approach, you will discover which one you end up with.
-====Calculating day of the week based on year====
-Okay, time for the magic.
-Let us try it on January 1st, 2014.
-===Step 1: Obtain last two digits of the year===
-In our example, we're working with 2014, the last two digits are therefore: 14
-You should be able to come up with a means of extracting this information in your program.
-===Step 2: Compute 25% (drop the decimal)===
-Even this is something we can do in our heads. I can think of two approaches right off the bat:
-==Approach 1: 10 + 10 + 5==
-% percent of anything is merely moving the decimal over one place to the left. 10% of 54 is 5.4
-For our 2014 example, 10% of 14 is therefore 1.4
-So we need two 10 percents... 1.4 + 1.4 = 2.8
-Finally, 5% is half of 10% (half of 1.4 is 0.7), so 1.4 + 1.4 + 0.7 = 3.5
-But, since we do not care about the decimal, we drop it and are left with just 3.
-==Approach 2: half of half==
-% is a convenient value for us with respect to 100, allowing this optimized approach to work.
-  * Half of 100 is 50 (50%)
-  * Half of 50 is 25 (25%) -- hence the "half of half"
-So, 14 cut in half is 7.
-cut in half is 3.5.
-Once again, dropping the decimal yields 3.
-===Step 3: Add 25% to year value===
-Once we have our 25% value, go and add it back to our two-digit year value:
-+ 3 = 17
-===Step 4: Subtract the largest fitting multiple of 7===
-Some multiples of 7:
-|  0  |  7  |  14  |  21  |  28  |  35  |  42  |  49  |
-So, with a value of 17, what is the largest multiple of 7 that is still less than (or equal to) 17?
-Hopefully you identified the 14 as the likely candidate.
-- 14 = 3
-===Step 5: Look up day in table===
-We ended up with a 3 as the result for January 1st, 2014.
-Go and reference the 3 from that table... what day do we get? Does it match the actual day of the week for January 1st, 2014?
 <cli>
-lab46:~$ cal 01 2014
+lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT
-    January 2014
-Su Mo Tu We Th Fr Sa
-  2  3  4
-  6  7  8  9 10 11
-13 14 15 16 17 18
-20 21 22 23 24 25
-27 28 29 30 31
-lab46:~$
 </cli>
-Pretty neat, eh?
+=====OVERVIEW=====
+Your task is to write a program that performs the mental math technique of determining what day of the week January 1st falls on for any year in the 21st century.
-====Exception: Leap Years====
+Contributing to project documentation is also a core part of this project. If from reading the existing documentation or through your own exploring, you find something lacking, unclear, or outright missing, that is an opportunity to potentially contribute content.
-In the event of a leap year, we simply subtract 1 from the 25% value, and continue on as usual.
-Makes sense, right? Leap years add a day, so something ends up being "off by one".
+You want the project documentation to provide you (as if coming in with no awareness of the project) with sufficient information so as to allow you to proceed. Asking questions on the discord is a great way of getting more information that you can use to add content.
-=====Program=====
+=====EDIT=====
-It is your task to write the program that will use the above method to determine the day of the week any given January 1st in the 21st century falls on.
+You will want to go [[/notes/cprog/fall2022/projects/dow0|here]] to edit and fill in the various sections of the document:
-Your program should:
+  * [[/notes/cprog/fall2022/projects/dow0|https://lab46.g7n.org/notes/cprog/fall2022/projects/dow0]]
-  * prompt the user for the four digit year (input)
-  * perform the task (process)
-  * display the final value (output)
-=====Execution=====
+{{page>notes:cprog:fall2022:projects:dow0&nouser&nodate&nomdate}}
-<cli>
+=====SUBMISSION=====
-lab46:~/src/SEMESTER/cprog/dow0$ ./dow0
+To be successful in this project, the following criteria (or their equivalent) must be met:
-Which year: 2014
-January 1st, 2014 falls on: Wednesday
-lab46:~/src/SEMESTER/cprog/dow0$
-</cli>
-The execution of the program is short and simple- obtain the input, do the processing, produce the output, and then terminate.
+  * Project must be submit on time, by the deadline.
+    * Late submissions will lose 33%  credit per day, with the submission window closing on the 3rd day following the deadline.
-====Output Specifications====
+  * All code must compile cleanly (no warnings or errors)
-Your program must output as follows:
+    * Compile with the **-Wall** and **--std=gnu18** compiler flags
+    * all  requested functionality  must conform  to stated  requirements (either on  this document or  in a comment banner in  source code files themselves).
-  * Input prompts, and everything else except the actual day of the week should be output to STDERR
+  * Executed programs must display in a manner similar to provided output
-  * The calculated day of the week needs to be displayed to STDOUT
+    * output  formatted,  where applicable,  must match  that of  project requirements
-  * The output MUST contain the "January 1st, YEAR" string
+  * Processing must be correct based on input given and output requested
-    * YEAR must be all 4 digits, exactly as input by the user
+  * Output, if applicable, must be correct based on values input
-  * The calculated day of the week must be fully spelled out and correct, with the first letter capitalized, remaining letters lowercase.
+  * Code must be nicely and consistently indented
-=====Reflection=====
+  * Code must be consistently written, to strive for readability from having a consistent style throughout
-Be sure to provide any commentary on your journal regarding realizations had and discoveries made during your pursuit of this project.
-  * Try this algorithm on some years in the 20th century and see how it fares.
-    * Is it correct? Is it correct for any of them?
-    * If it isn't correct, is it consistently off by a value?
-This isn't just about implementing a particular algorithm, it is about understanding an algorithm- its domain of correctness, and its limitations.
-=====Submission=====
-To successfully complete this project, the following criteria must be met:
-  * Code must compile cleanly (no warnings or errors)
-  * Executed program must display a total of 2 lines, one for input, one for output.
-  * Input **must** be in the form of a complete (i.e. four-digit) year
-    * input must be a number, NOT a string
-  * Output must be correct, and match the form given in the sample output above.
-  * Code must be nicely and consistently indented (you may use the **indent** tool)
   * Code must be commented
-  * Output Formatting (including spacing) of program must conform to the provided output (see above).
+    * Any "to be implemented" comments **MUST** be removed
-  * Track/version the source code in a repository
+      * these   "to  be  implemented"   comments,  if  still  present  at evaluation time, will result in points being deducted.
-  * Submit a copy of your source code to me using the **submit** tool.
+      * Sufficient  comments  explaining  the point  of  provided   logic **MUST** be present
+  * No global variables (without instructor approval), no goto statements, no calling of main()!
+  * Track/version the source code in your lab46 semester repository
+  * Submit  a copy of  your source code to  me using the  **submit** tool (**make submit** on lab46 will do this) by the deadline.
-To submit this program to me, use the **submit** rule to the Makefile; run the following command at your lab46 prompt:
+====Submit Tool Usage====
+Let's  say you  have completed  work  on the  project, and  are ready  to
+submit, you  would do the following  (assuming you have a  program called
+uom0.c):
 <cli>
-lab46:~/src/SEMESTER/cprog/dow0$ make submit
+lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit
 </cli>
-You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.
+You should get some sort of confirmation indicating successful submission
+if all went according to plan. If  not, check for typos and or locational
+mismatches.
-What I'll be looking for:
+=====RUBRIC=====
+I'll be evaluating the project based on the following criteria:
 <code>
-:dow0:final tally of results (52/52)
+:dow0:final tally of results (39/39)
-*:dow0:obtained via grabit by Sunday before deadline [4/4]
+*:dow0:used grabit to obtain project by the Sunday prior to duedate [6/6]
-*:dow0:program compiles successfully, no errors [4/4]
+*:dow0:clean compile, no compiler messages [7/7]
-*:dow0:program compiles with no warnings [4/4]
+*:dow0:program conforms to project specifications [20/20]
-*:dow0:program performs stated task/algorithm [4/4]
+*:dow0:code tracked in lab46 semester repo [6/6]
-*:dow0:program output conforms to formatting expectations [4/4]
-*:dow0:proper error checking and status reporting performed [4/4]
-*:dow0:code implements solution using relevant concepts [4/4]
-*:dow0:code updates committed/pushed to lab46 semester repo [4/4]
-*:dow0:code uses correct variable types and name lengths [4/4]
-*:dow0:project is submitted with relevant and complete source [4/4]
-*:dow0:project is submitted on lab46 using 'make submit' [4/4]
-*:dow0:project is submitted with pi and lab46 binaries [4/4]
-*:dow0:runtime tests of submitted program succeed [4/4]
 </code>
-Additionally:
+===Pertaining to the collaborative authoring of project documentation===
-  * Solutions not abiding by **SPIRIT** of project will be subject to a 25% overall deduction
-  * Solutions not utilizing descriptive why and how **COMMENTS** will be subject to a 25% overall deduction
+  * each class member is to participate in the contribution of relevant information and formatting of the documentation
-  * Solutions not utilizing **INDENTATION** to promote scope and clarity will be subject to a 25% overall deduction
+    * minimal member contributions consist of:
-  * Solutions lacking **ORGANIZATION** and are not easy to read (within 90 char width) are subject to a 25% overall deduction
+      * near the class average edits (a value of at least four productive edits)
+      * near the average class content change average (a value of at least 256 bytes (absolute value of data content change))
+      * near the class content contribution average (a value of at least 1kiB)
+      * no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements
+    * adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
+    * content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
+      * no contributions, co-efficient is 0.50
+      * less than minimum contributions is 0.75
+      * met minimum contribution threshold is 1.00
+===Additionally===
+  * Solutions not abiding  by spirit of project will be  subject to a 50% overall deduction
+  * Solutions  not  utilizing descriptive  why and  how comments  will be subject to a 25% overall deduction
+  * 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
+  * 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

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools