User Tools

Site Tools


Sidebar

projects

wcp1 (due 20220824)
fwf0 (due 20220831)
ntr0 (due 20220831)
pct1 (bonus; due 20220831)
wcp2 (due 20220831)
dtr0 (due 20220907)
pct2 (due 20220907)
pct3 (bonus; due 20220907)
wcp3 (due 20220907)
sof0 (due 20220914)
wcp4 (due 20220914)
pct4 (due 20220915)
dow0 (due 20220921)
wcp5 (due 20220921)
pct5 (bonus; due 20220922)
cnv0 (due 20220928)
gfo0 (due 20220928)
wcp6 (due 20220928)
pct6 (due 20220929)
cnv1 (due 20221005)
pct7 (bonus; due 20221005)
wcp7 (due 20221005)
bwp1 (bonus; due 20221019)
cbf0 (due 20221019)
pct8 (due 20221019)
wcp8 (due 20221019)
pct9 (bonus; due 20221026)
wcp9 (due 20221026)
gfo1 (due 20221102)
pctA (due 20221102)
sam0 (due 20221102)
wcpA (due 20221102)
pctB (bonus; due 20221109)
wcpB (due 20221109)
oop0 (due 20221110)
oop1 (due 20221116)
pctC (due 20221116)
wcpC (due 20221116)
bwp2 (bonus; due 20221201)
oop2 (due 20221201)
pctD (bonus; due 20221201)
wcpD (bonus; due 20221201)
pctE (bonus; due 20221207)
wcpE (bonus; due 20221207)
gfo2 (due 20221208)
EoCE (due 20221219)
haas:fall2022:cprog:projects:dow0

Corning Community College

CSCS1320 C/C++ Programming

PROJECT: MENTAL MATH - DAY OF WEEK (DOW0)

OBJECTIVE

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.

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.

lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT

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.

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.

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.

EDIT

You will want to go here to edit and fill in the various sections of the document:

BACKGROUND

You need to create a program that will calculate exactly what day of the week will be on January 1st for the entire century. To do this there are simple methods for the math behind the calculations, You can find an example here https://www.almanac.com/how-find-day-week

SPECIFICATIONS

PROGRAM

OUTPUT SPECIFICATIONS

VERIFICATION

To verify your code, there is a program in the project files, named “dow0verify”. This will run through your program, inputting each year from 2000 - 2099 to check if your output is correct.

For each line, the program will give you the following:

  • The year that was entered
  • The expected output
  • What your program actually output
  • If the test failed or succeeded

At the end, the verification program will tell you how which years your output did not match, and it will give you a final score of how many years you got right.

NOTE: Your Raspberry pi is a 32-bit system. Due to memory limitations and how computers handle time and dates, the verification program will NOT work on your pi past the year 2038. You will have to run it on lab46, which is 64-bit.

You can use this program to verify that your code gives the right answers, as well outputting that answer in the correct way.

 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • 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.
  • All code must compile cleanly (no warnings or errors)
    • 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).
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • 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.

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):

lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit

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.

RUBRIC

I'll be evaluating the project based on the following criteria:

39:dow0:final tally of results (39/39)
*:dow0:used grabit to obtain project by the Sunday prior to duedate [6/6]
*:dow0:clean compile, no compiler messages [7/7]
*:dow0:program conforms to project specifications [20/20]
*:dow0:code tracked in lab46 semester repo [6/6]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • 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
haas/fall2022/cprog/projects/dow0.txt · Last modified: 2022/09/23 21:26 by wedge