CS 112 Syllabus - Fall 2018

1 Course Basics

1.2 Course Outcomes

  1. An ability to use procedural programming language concepts including expressions, decision statements, simple data types, Boolean logic, input/output, loop constructs, and procedures.
  2. An ability to combine programming techniques to solve problems of varying degrees of difficulty.
  3. An ability to refine computer programs through testing and debugging to ensure proper operation.
  4. An ability to find and understand programming language documentation to learn new information needed to solve programming problems.

Additionally, CS 112 satisfies the "Information Technology and Computing" Mason Core requirements, which fosters these Learning Outcomes:

  1. Students will understand the principles of information storage, exchange, security, and privacy and be aware of related ethical issues.
  2. Students will become critical consumers of digital information; they will be capable of selecting and evaluating appropriate, relevant, and trustworthy sources of information.
  3. Students can use appropriate information and computing technologies to organize and analyze information and use it to guide decision-making.
  4. Students will be able to choose and apply appropriate algorithmic methods to solve a problem.

1.3 Prerequisite

C or better in MATH 104, 105, or 113, or sufficient score on the math placement test.

1.4 Contact Information

Sections Professor office email
-002 Jitin Krishnan ENGR 4417 jkrishn2@gmu.edu
-003 Mark Snyder ENGR 4300 msnyde14@gmu.edu
    (office hours in ENGR 4201)  
-004, -005 Yutao Zhong ENGR 4433 yzhong@gmu.edu
-009 Socrates Dimitriadis ENGR 4417 sdimitr@gmu.edu

1.5 Text: Zyante

  • Required - Zyante online text.
    1. Sign up at zybooks.com.
    2. Enter zyBook code: GMUCS112Fall2018
    3. Subscribe (indicate your lecture section when prompted)

1.6 Piazza

  • sign up: http://piazza.com/gmu/fall2018/cs112
  • All correspondence will go through Piazza. You can send private messages to the instructors (professors, GTAs, UTAs all) as well as post public questions visible to all students, collaborate on responses, and tag everything by topic.
    • Unless you have a confidential matter to discuss directly with an individual professor, please do not email us directly, use a private piazza post or visit in person. Project help questions sent via email are extremely low priority, as they were sent to the wrong place.
  • Course discussions will take place on Piazza. Go sign up now so you don't miss announcements.
  • Documents such as TA contacts, schedules, and lecture slides will be on piazza only (not blackboard).

1.7 Blackboard

  • Grades will be posted to Blackboard: https://mymason.gmu.edu
  • All assignments will be submitted (per published deadlines) via Blackboard.

1.8 In-Class Participation

  • We will use an online tool, Pytania, to interactively answer questions in class. That means you'll need to bring a wifi-enabled device - a laptop, phone, tablet - so you can log in, answer questions, and get credit for the day.
    • you earn class participation credit for the fraction of questions answered, right or wrong.
    • you earn extra credit for correct answers. (Great way to make up for missed questions!)
    • There will be a small allotment of questions you can miss and still get full credit, so if you miss an individual question here or there, it's okay - just get some correct-answer extra credit and you're back on track!
  • Note that attempting to answer questions to any online class participation system from home is not permitted. That would be a violation of the honor code, and we would recommend failure in the course as with any other honor code violation.

1.9 Optional Reading

  • Quite Optional - The Practice of Computing Using Python, William Punch and Richard Enbody. This is for students who want extra reading resources. You might be able to view a copy for free at Fenwick Library.

2 Grading

The course will have two tests and a final. Much of the effort during the semester will be completing projects, as well as regular assessments in lab (exercises, quizzes, and programming tasks).

In general, all grades should be available about one week after the deadline. We will often have Sunday project deadlines (plus 48 hours of late work accepted), so you would usually get a grade posted by the following week's Wednesday.

2.1 Semester Grade Composition

Category Percent Notes
Projects 40% drop 1 lowest
Labs 10% drop 2 lowest, average others evenly.
Class participation 2% up to 1% bonus for correct answers
Zyante readings 3% drop lowest deadline grade
Tests (10% each) 20% (10% each test)
Final Exam 25%  
  • Given the percentages above and the allowed dropped lowest grades, you should always be able to calculate your semester grade at any point in the semester.
  • There will be no make-up or extra-credit assignments at the end of the semester; your grade should be a measure of your semester-long progress.
  • note that generally, project/lab scores are higher, and test scores lower, than many students' overall semester score.
  • here is an unofficial grade calculator that you can use to track your progress and run "what if?" scenarios:

Grades will be assessed on the following scale:

Grade Score Grade Score Grade Score Grade Score
A+ 98 % B+ 88% C+ 78% D 60%
A 92 % B 82% C 72% F 0%
A- 90 % B- 80% C- 70%    

2.2 Projects

Each programming assignment is an individual effort; no collaboration allowed on projects.

Programming projects will be a primary focus of your experience, progress, and grade - each one should take multiple sessions of coding, with questions asked of the course instructors in person or online in between those sessions. This is the practice you need to learn, master, and internalize various concepts of the course.

2.2.1 Deadlines, Tokens

  • Each project has a posted deadline.
  • The latest you can turn in work is 48 hours after the posted deadline. There are no exceptions to this limit.
  • each student gets three One-Late-Day tokens, which are automatically used by submissions that are between 0-48 hours late to avoid the points penalty associated with that day of lateness. You still must turn in work within 48 hours of the original deadline, even if you use tokens! (that means you can't use all three tokens on a single project - pace yourself!)
  • each day late (or portion thereof), when not covered by a token, lowers the highest possible score by 25%. recorded_grade = min(raw_score, 100-25*num_days_late)
  • the last project might not be allowed to be turned in late, to facilitate end-of-semester grading.
  • tokens are automatically applied to projects based on submission timestamp. You can use tokens on labs if you manually request it, but be advised they are far more valuable for projects or keeping until semester's end.
  • unused late-tokens will be worth a small bounty at the semester's end (0.25% of the semester grade).

2.2.2 Broken Code == Bad Scores

After the first two projects, any code turned in that does not run (immediately crashes due to errors), specifically on Python 3.6 or greater, will receive at most 50%. At this point, if the grader is able to quickly fix your code, you might get some points back. If the grader cannot immediately spot and fix the issue, you'll be fortunate to get any points at all.

  • Turning in code that runs is a big deal!

2.2.3 Turning it in on BlackBoard

You can submit your work an unlimited number of times to BlackBoard, and by default only the last submission before the 48-hour limit deadline will be graded. You can also download your submitted attempts, and verify that you turned in a working copy.

  • Turning in the wrong files (including empty or partial-work copies) will likely result in a zero. Don't lose your one project-drop this way!
  • There is a difference between choosing to "save" your submission, meaning you'll come back and finish turning in your work, and choosing to "submit" your work, meaning actually sending the files to the instructors at a specific timestamp as a submission. If you've saved but not submitted, you haven't turned in your work yet!
  • Catastrophic computer failure will not be cause for an extension. Use a backup service such as DropBox (or any cloud service), emailing yourself, storing to a USB drive, whatever it takes. Every semester multiple students have their computers die, have computers stolen, or otherwise 'lose' projects. Don't be the student who forgot to (frequently) back up your work - it'll cost tokens and a rushed re-implementation! There are computer labs on campus where you can write and run python code if you have any temporary machine issues.

2.3 Lab Assessments

  • All lab assessment grades will be averaged together evenly. Lab assessments will be weekly exercises, tasks, or quizzes. Time in lab will often be available to seek assistance on projects when you've completed the lab task.
  • Lab Exercises are open to all collaboration, but Lab Quizzes and Lab Tasks are entirely individual efforts; no resources may be used on them.
  • We will drop the lowest two grades from this category.
  • Any missed lab assessment is simply missed, regardless of the reason why (travel, illness, work, traffic, receiving a major award, getting married, saving the universe, etc.). This is the reason you get lab drops! We don't consider further makeups.
  • labs may only be turned in late by spending tokens; be advised that tokens are far more valuable on projects. If you are out of tokens, you can't turn in a late lab.
  • If you choose to miss some labs early on, and later on have to miss for some understandable reason, that is too bad. Try to save the drops so you can actually throw out a bad grade, and not just hide a lazy zero. Pretending you don't have them is your best approach.

2.4 Tests and Final Exam

  • As a requirement for passing this course, students must have a passing grade on either (a) the weighted average of all tests/exams or (b) on a cumulative final exam. The university defines "passing" as earning a grade of D or higher. Students who meet this requirement will earn the grade indicated by the weightings listed in this document; those who do not will fail the course.
  • these tests will focus on performing programming, on paper.
  • all students must have their GMU identification available on testing days.
  • the final exam is cumulative. If you perform better on the final exam than a previous test, we will replace the test grade with the final grade.
  • if you miss the final, there is nothing we can do for you. Don't miss the final!
  • the final will not be given early. You are starting the course with knowledge of the schedule. Plan on being in Fairfax for the entire exam period, as weather can cause unexpected delays in the examination schedule.
  • there will only be a curve if specific questions end up being too ambiguous or otherwise obviously unfair - we don't target some mythical bell curve; everyone can do very well!

2.5 Contested Grades

  • If you feel points have been incorrectly deducted, contact the grader. For all projects and lab work, that is either your GTA who leads the lab section, or a different GTA who signed their name on the grading comments under rare circumstances. For the tests and final exam, that is your professor.
  • If you have not initiated contact within a week of a grade being posted to BlackBoard, you accept the grade by default. We cannot entertain a swarm of contested grades at the eleventh hour to try to maximize end-of-semester grades. Keep up with your grades throughout the semester.
  • We strive to grade each student's work fairly and uniformly, often through specific test cases, automated as part of the grading process. All GTAs coordinate together with a shared scoring breakdown and regularly communicate with each other before, during, and after the grading process to keep it fair and consistent.

3 The Honor Code

  • The honor code at George Mason is an important part of our academic culture. A degree from this institution should be a direct measure of your own progress and abilities, and as such at all times we must ensure that all work that should be your own is your own.
  • The CS department doesn't have any "extra" policy for the honor code on top of the university's. The documents shared below help you to understand how it applies to programming and CS but they don't actually restrict it at all.
  • We take the honor code quite seriously. Any attempts at copying or sharing code, algorithms, or other violations of the honor code simply will not be tolerated. This includes using code found on the internet.
  • There are definitely opportunities to study, work, and learn together throughout this course - Zyante questions, lab exercises, and more. Mostly you will need to work independently for any sort of "test" (lab quizzes, lab tasks, tests, final exam) and for projects.
  • As seductively simple as it may seem to just copy and paste work from a friend, or even to just work on the project on your own machines next to each other, remember that it is just as easy to compare your work automatically and electronically, and discover the similarities in text and structure. We use automated software to flag suspicious cases, and then review them by hand to find the cases that must be submitted to the Office of Academic Integrity. Repeat to yourself: it's not worth trying to cheat. We will catch it, and sadly but surely, we will turn it in.
  • The penalty for cheating will always be far worse than a zero grade, to ensure it's not worth taking the chance. Confirmed cases of cheating almost always translate into course failure.
  • discussing any individually assigned work with anyone other than a course instructor, UTA, or GTA is explicitly forbidden, regardless of medium (in person, online, through "chat" features, etc).

3.1 Some Specifics and Links

  • All students will abide by GMU's Honor Code.
  • All work must be your own. If you are caught cheating, you and every other involved student must be turned in to the honor court.
  • See the CS Honor Code Policies to understand better what constitutes cheating in the CS setting. It clarifies some scenarios that are unique to our sorts of assignments.
  • Understanding the Honor Code: here are Dr. Snyder's own thoughts about the purpose of the honor code in a computer science course.

4 Learning Disabilities

  • Students with a learning disability or other condition (documented with GMU's Office of Disability Services) that may impact academic performance should speak with the professor ASAP to discuss appropriate accommodations. We are quite happy to assist as is appropriate, but it must be documented ahead of time. Bringing the accommodation paperwork with you to a scheduled assessment is far too late! Even if you don't know if you plan on utilizing the accommodations ahead of time, it's in your best interest to prepare ahead of time.