Announcements

ICS-33: Intermediate Programming

In reverse-chronological order

#23: 6/15/2018
Program #5 Graded
The TAs have run the rubric that I gave them for Program #5 (observing the behavior of your simulations, and looking at your code for inheritance) and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 89% and the median was 96%, meaning that most students correctly solved most problems, and over half (71%) of the class correctly solved all the problems (or had minor deductions). Note that this problem had extra credit for an early submission. Overall there were 71% As, 14% Bs, 5% Cs, and 10% Ds and Fs.

About 42% of the students submitted early, and these early submitters scored much better (average 997) than students submitting on the due day (average 82%); I am assuming that some students ran out of time before they finished all the problems.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order); Column B contains an X if we believe the student submitted work on time; Column C shows who graded your program; Column D shows the extra credit points for early submissions.

Row 2 shows the worth (in number of points) for each part of the problem. Rows 4-5 shows further information about the tests performed in each column.

Rows 6 and beyond show credit awarded for each student: a blank cell means full credit, X means no credit, and P means partial credit. Each of these marks should have a comment attached to it with the TAs brief description of the problem. Column R shows each student's cumulative score, for all the parts in the single problem in this assignment. Columns S-T show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 50).

Note the following instructions were in the assignment:

When you define these classes, you should not modify any code written in their base classes. You should also not access by name or duplicate an instance variables (attributes) that are inherited. You can call methods in the bases classes to access/update their instance variables and override any methods in the base clases (whose bodies might call the overridden methods to help them accomplish their task). You can also define new methods. Each leaf class must define or inherit an update and display method, which respectively implement the behavior of objects in that class and the image that they display on the canvas.

There were lots of deductions in the last two columns, so I reduced their worth to just 2 pts each: even students who got an X in both columns could score 92% (more for early submissions). My grading instructions to the TAs were as follows. Although subjective, the averages for all the programs the TAs graded were within a few points of each other, so grading was consistent.

  • For Specials, observe any "interesting behavior" (can you see something; just changing a size/color is not interesting).
    1. If no comment in module telling what it does: P
    2. If no noticeable interesting behavior: P
    3. If neither comment nor interesting code (also, not submitted): X

  • For the model class (upddate_all) and the Hunter class (update) examine the code.
    1. if update_all loops over multiple sets (e.g., one per type of simulton) or does removals (individual classes should): X
    2. if update-all calls type or isinstance (the update methods of the classes should do this): X
    3. if Hunter doesn't derive fromPulsator/call Pulsator.method: X
    4. if Hunter refers to self._anything (underscore variables): X
    5. if Hunder has a loop (find in the model and Pulsator should do the heavy lifting in his class): P

This assignment was designed to illustrate the mechanics of Python inheritance, and its use to minimize code (including multiple inheritance, once). It also illustrated the Model-View-Controller (MVC) way of writing Graphical User Interface (GUI) applications, with the student supplying code related to the Model onlyl, and me supplying code for the View and Controller for its animation.


#22: 6/11/18
Quiz #8 Graded
The TAs have graded the code and document submissions for Quiz #8. The grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7.

The class average was about 82% and the median was 84%, meaning that most students correctly solved most problems, and many (34%) of the class correctly solved all the problems (or had minor deductions). Overall there were 31% As, 39% Bs, 15% Cs, and 16% Ds and Fs.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-G shows how many points the problems were worth.

Rows 4 and beyond show the number of points earned by each student.. Columns H-J show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

The problems were graded by many different TAs and Readers (not in a way that will make sense on this spreadsheet). If you have questions about grading contact me; make sure to examine my solution first. Here is a quick overview of the general rubric (see my answers online).

  • Problem #1a: The first lambda should time closest_2d called on a pre-existing random list (not constructed during the timing); the second lambda should create a new random list on which closest_2d is run; typically this requires the use/setting of a global variable. The numbers should increase by about a factor of 2 and a bit more; it should produce appropriately labeled output (as appears in the sample.pdf): the output header includes Neighest Neighbor, size = ...

  • Problem #1b: Ratios should be a bit larger than 2; complexity is O(N Log N) If you measured some ratios smaller than 2 that is fine too; we counted O(N) as a correct answer. Your answer must have been written correctly using big-O notation.

  • Problem #2a: Profiling should not include generation of random list; the first output should be decreasing by ncalls and the second by tottime, showing the top 15 functions (with their directories stripped, as shown in the lecture notes).

  • Problem #2b: Answers to problems 1, 2a, and 2c were worth 1 pt each (because of a poor statement of what I wanted for part 2b, the TAs did not grade that part).

  • Problem #3: We tested this code not by running it as is, but by running it with a defective Bag class (whose remove method was written incorrectly as just return), so the count, equals, len and remove tests should fail; others should pass. You needed to have multiple forms of self.assertXXX not always just self.assertTrue or self.assertFalse; for remove you needed to use self.assertRaises correctly.

This assignment was designed to provide you with an opportunity to use the performance and correctness tools on a small scale, in the context of problems related to analyzing algorithms and code. In the case of the performance tools, it is easy to scale up and measture arbitrarily complicated code. As with all assignments, you should examine my solutions.


#21: 6/4/18
Quiz #7 Graded
The TAs have graded the paper submissions for Quiz #7. The grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 80% and the median was 84%, meaning that some students correctly solved most problems, but less than half (32%) of the class correctly solved all the problems (or had minor deductions). Overall there were 32% As, 29% Bs, 18% Cs, and 21% Ds and Fs.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 in Columns D-I shows how many points the problems were worth; Column C shows a 2 point deduction for students submitting late and a 5 point deduction for not using a single sheet of paper (I originally said we would not even grade such submissions; students who did not submit one, two-sided sheet should retrieve their quizzes from me during my office hours, not their TA in Lab).

Rows 3 and beyond show the number of points earned by each student. Columns J-L show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

The TAs graded the following problems.

  Seyyed    : 1
  James     : 2
  Richard   : 3
  Tianhang  : 4
  Radu      : 5
  Juan      : 6
These papers will be returned in lab on Tuesday and Thursday. Students should talk to the appropriate TA first, if they do not understand why they received the marks they did. The best time to talk with any TA about grades is during one of their Labs.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

This assignment was designed to provide you with an introduction to solving problems related to analyzing algorithms and code. All these topics may be tested again on the Final exam. As with all assignments, you should examine my solutions.


#20: 5/31/18
Program #4 Graded
I have run the automatic batch self-check tests for Program #4 and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 98% and the median was 100%, meaning that most students correctly solved most problems, and over half (92%) of the class correctly solved all the problems (or had minor deductions). Note that this problem had an extra credit part, as well as extra credit for an early submission. Overall there were 92% As, 3% Bs, 1% Cs, and 4% Ds and Fs. Overall there were 95% As, 2% Bs, 1% Cs, and 1% Ds and Fs. About 35% of the students submitted early, and these early submitters scored better (average 104%) than students submitting on the due day (average 95%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later program.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order); Column B contains an X if we believe the student submitted work on time (for pairs, only the submitting student will show an X, not their partner); Column C shows the extra credit points for early submissions

Row 2 shows the worth (in number of points) for each problem. Row 3 shows the number of tests performed for each problem: all were batch-self check tests. Rows 4-5 shows further information about the tests performed in each column.

Rows 6 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 1 of 4 tests on a 4 point problem, he/she would receive 3/4*4 = 3 points. Column P shows each student's cumulative score, for all the tests in the single problem in this assignment. Columns Q-S show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 50). Note that these columns are filled in both for submitters and their partners (these are the only columns filled in for partners): a partner should see his/her submitter's line for details.

To get the extra credit point for processing string annotations (Column O), your code must pass all 6 tests.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in some part and therefore failed all that part's tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

  • A few students submitted code that (a) incorrectly named partners -wrong format or wrong UCInetID, or (b) had students listed a partners of multiple submitters, or (c) had both students submitting and listed as partners of submitters. The TAs are authorized to try to understand these problems and help me correct them (but, I will deduct some points for dealing with these problems).

This assignment was designed to illustrate the mutual recursion used for checking annotations (parameter and return) for functions, by overloading the __call__ method in a class, creating a function decorator. As with all assignments, you should examine my solutions.


#19: 5/28/18
Quiz #6 Graded
I have run the automatic batch self-check tests for Quiz #6 and the TAs have graded the paper submissions. I used the following batch self-check files (similar to the ones I provided, but with some altered/additional tests). The grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 78% and the median was 84%, meaning that most students correctly solved most problems, and almost half (38%) of the class correctly solved all the problems (or had minor deductions). Overall, there were 38% As, 23% Bs, 10% Cs, and 129 Ds and Fs. About 27% of the students submitted early (to Checkmate), and these early submitters scored better (average of 93%) than students submitting on the due day (average of 72%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work. Row 1 for Columns D-I shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem.

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive 15/20*4 = 3 points. Columns J-N show the cumulative score for each Problem. Columns P-Q show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

TAs graded the paper submissions for their Labs. The TAs will return the written quizzes in their lab on Tuesday. The written problems were graded as follows:

  • For the list problem, fully correct references and cross-outs in a, t, and b were worth 1 point each (.5 pts if some but not all were correc); three fully correct references and cross-outs for the LN's next fields (between the linked list nodes) were worth 1 point each total (.5 pts if links were correct but not crossouts). Not drawing the tail of the arrows fully inside the boxes (those are the values stored in these boxes/attributes) was an additional .5 pt deduction.

  • For the binary search tree problem, getting the root/left subtree correct was worth 1 pts; getting the root/right subtree correct was worth 1 pt (no partial credit here); gettting th Size/Height both correct in the box was worth 1 pt total (almost everyone got Size correct, but some specified Height as 8, which does not use the defintion of Height from the notes).

Students should talk to their TA, if they do not understand why they received the marks they did. The best time to talk with any TA about grades is during one of their Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

This assignment was designed to provide you with a chance to demonstrate you understand the execution of linked-list and binary search tree algorithms. Also, it served as an introduction to coding linked-list and tree functions, involving iteration and recursion. Finallly, it also allowed you to experiment with a derived class. All these topics may be tested again on the Final exam. As with all assignments, you should examine my solutions.

#18: 5/24/18
In-Lab Programming Exam #2 Graded
I have run the automatic batch self-check tests for In-Lab Exam #2 and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. You can find your solutions, my solution, and the bscile2S18.txt file I used to compute grades for this assignment in the EEE dropbox for this class (see the name ile2studentsolutions). If you scored better on In-Lab Exam #2 than on In-Lab Exam #1, your score for this exam will be highlighted in yellow, and the sum of these two scores (column W in the grades spreadsheet) will be 2 * (your score for In-Lab Exam #2). Som students scored better on In-Lab #2: 67% scored the same or higher (or still got 100%, just not the extra credit they got on In-Lab Exam #1); 32% scored lower.

The class average was about 86% and the median was about 98%. The skew between these statistics shows that although the majority of students did very well, there were some students who did very poorly, dragging down the average but not the median. At the extremes, 48% of the students scored 100% or more (because of the extra credit point; all methods passed all batch self-check tests).

The approximate distribution of grades on this In-Lab exam is 60% As, 12% Bs, 7% Cs, 6% Ds, and 14% Fs (last quarter the distribution was 64% As, 6% Bs, 6% Cs, 6% Ds, and 15% Fs).

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • If there is a comment in column B (the one with the X) saying that you submitted an empty folder, contact me (Rich).

  • If you submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • If you submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).
Finally, the batch self-check tests for grading were identical to the tests in the script of the exam. 12% of the students solved the extra credit problem fully.

#17: 5/20/18
Quiz #5 Graded
I have run the automatic batch self-check tests for Quiz #5. The grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 92% and the median was 96%, meaning that most students correctly solved most problems, and over half (71%) of the class correctly solved all the problems (or had minor deductions). Overall there were 71% As, 24% Bs, 1% Cs, and 4% Ds and Fs. About 35% of the students submitted early, and these early submitters scored much better (average of 96%) than students submitting on the due day (average of 89%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-I shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive 15/20*4 = 3 points. Columns R-V show the cumulative score for each Problem. Columns W-Y show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

Appropriate recursive code contains no

  • for/while loops or comprehensions,
  • try/except statements (it should use if/else)
  • rebinding of parameters/local variables (including no use of = nor +=)
  • mutation of data: e.g., no calls to pop, remove, del, append, add, insert, extend, etc.)
  • extra data structures: no creation of tuples, lists, sets, dicts, etc.
  • no calls to sort (the Python builtin) or sorted
The compare function should contain no comparison operators on strings longer than 1 character.

The purpose of the assignment was to improve your ability to write recursive functions correctly, according to the constraints of functional programming.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

This assignment was designed to provide you with an introduction to the use of recursive functions. All these topics may appear on the Final exam. As with all assignments, you should examine my solutions.

#16: 5/17/18
Program #3 Graded
I have run the automatic batch self-check tests for Program #3 and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. I used a different bsc test file for grading: one that defined a pnamedtuple('Quad1', 'x y z f'), having a different number of fields with different names not in alphabetical order. The class average was about 98% and the median was 104%, meaning that most students correctly solved most problems, and over half (90%) of the class correctly solved all the problems (or had minor deductions). Note that this problem had an extra credit part, as well as the standard extra credit for an early submission. Overall there were 90% As, 2% Bs, 2% Cs, and 6% Ds and Fs. About 50% of the students submitted early, and these early submitters scored better (average of 102%) than students submitting on the due day (average of 95%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later program.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order); Column B contains an X if we believe the student submitted work on time (for pairs, only the submitting student will show an X, not their partner); Column C shows the extra credit points for early submissions (students submitting a few minutes late show -2; students submitting more than a few minutes late were not graded).

Row 2 shows the number of points each group of batch-self checks is worth; row 3 shows the number of tests performed for each problem: all were batch-self check tests. Rows 4-5 shows further information about the tests performed in each column.

Rows 6 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 1 of 4 tests on a 4 point problem, he/she would receive 3/4*4 = 3 points. Column L shows each student's cumulative score, for all the tests in the single problem in this assignment. Columns M-O show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 50). Note that these columns are filled in both for submitters and their partners (these are the only columns filled in for partners): a partner should see his/her submitter's line for details.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in some part and therefore failed all that part's tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but I will deduct some points for submitting code with an infinite loop).

  • A few students submitted code that (a) incorrectly named partners -wrong format or wrong UCInetID, or (b) had students listed a partners of multiple submitters, or (c) had both students submitting and listed as partners of submitters. The TAs are authorized to try to understand these problems and help me correct them (but, I will deduct some points for dealing with these problems).

This assignment was designed to illustrate the richness of ways to solve programming problems: writing a program that automatically writes a class, given the required information to specify it (class name and fields). It also provided an opportunity to improve your string-processing abilities. As with all assignments, you should examine my solution.


#15: 5/14/18
Midterm Graded
The staff and I have graded and recorded the scores for the midterm exam. The staff will distribute the graded midterms in their labs this week. If you do not pick up your exam then, you will have to come to my office hours to retrieve it (and I would prefer not to have hundreds of exams stockpiled in my office). See the assignment grades and Grades(zipped .xlsm file) files.

The class average was about 61% and the median was 63% (last Spring they were 65% and 65%). Because the average was below 75%, about 17 normalization points (14%) will be added when computing the average of all graded instruments on the spreadsheet. The grades recorded in the spreadsheet (both in Columns R and S) are the actual exam grades (without normalization points; see cell R8, highlighted in yellow, for the number of normalization points that will boost your score). After normalizing the scores on the midterm, overall there were 22% As, 21% Bs, 24% Cs, 14% Ds, and 19% Fs (last Spring there were 17% As, 25% Bs, 26% Cs, 18% Ds, and 14% Fs; that is a pretty close match). I will show some more detailed information about the exam in lecture on Wednesday.

Now is a good time to look at course grades as well, as we have graded nearly half of the total number of testing instruments (450 of 1,000 points). Now is the first time that recorded grades are truly meaningful, because they include testing instruments in all the major categories: quizzes, programs, in-lab exams, and written exams. The approximate distribution of course grades (for those students who submitted a midterm exam) is 43% As, 22% Bs, 13% Cs, and 22% Ds and Fs: these numbers are better than my original prediction of of 25% in each of these four categories (e.g., we have 64% As and Bs instead of 50% As and Bs).

The different problems, with the indicated averages, were graded by the following staff.

  • Problem 1: 57% Functions on Data Structures (Rich)
  • Problem 2: 62% Regular Expressions (Tiehang)
  • Problem 3: 79% Operator Overloading 1 (Seyyed)
  • Problem 4: 72% Operator Overloading 2 (Richard)
  • Problem 5: 52% Iterators/Generators (Radu)
  • Problem 6: 63% Recursion/Functional Programming (James)
  • Problem 7: 44% Attributes, Operators and FEEOP (Juan)
  • Problem 8: 35% Short Answer (Rich)
I would like to thank the TAs/Readers for their efforts over the weekend (each spent about 16 hours preparing to grade, grading their problems on about 350 exams, and then entering the grades for their labs of students).

If you have any issues with how any exam problem was graded, talk to the staff member who graded it, and they can discuss the rubric with you and resolve any issues. But first, please examine my solution and understand the differences between it and your answer. Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned). Note: Because we examined code (unlike for the In-Lab exam) partially credit was awarded, but sometimes points were deducted not for correctness issues, but for stylistic issues: e.g., using extra data structures/loops, not using boolean values or unpacking appropriately, etc.

Imporant: As with the In-Lab Exams, if a student performs better on the Final Exam (since it is cumulative), I will increase their Midterm Exam score by some yet to be determined anounce (somewhere betwee 50% of the Midterm Exam and 50% of the Final Exam up to 100% of the Final Exam.

Finally, the normalized average for the 10am labs was 75%, the 12noon labs was 75%, and 2pm labs was 75%: all the same. The highest scoring lab scored 79%, the lowest 69% (both were at 2pm).


#14: 5/9/18
Quiz #4 Graded
I have run the automatic batch self-check tests for Quiz #4 and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 88% and the median was 100%, meaning that most students correctly solved most problems, and over half (77%) of the class correctly solved all the problems (or had minor deductions). Overall there were 77% As, 6% Bs, 3% Cs, and 14% Ds and Fs. About 29% of the students submitted early, and these early submitters scored much better (100% average) than students submitting on the due day (84%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-I shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem. Row 3 shows the part of the problems in more detail.

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive 15/20*4 = 3 points. Columns J-K show the cumulative score for each Problem. Columns L-N show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

This assignment was designed to provide you with a good grounding in the use of iterators and generators (which can be used to implement iterators), and how to write code that uses iter and next directly (using while loop instead of for loop). All these topics will be tested again on the Midterm and In-Lab Exam #2. As with all assignments, you should examine my solutions.

#14: 5/6/18
Quiz #4 Graded
I have run the automatic batch self-check tests for Quiz #4 and the grades are now recorded. I used the following batch self-check files (similar to the ones I provided, but with some altered/additional tests). See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 84% and the median was 96%, meaning that most students correctly solved most problems, and over half (69%) of the class correctly solved all the problems (or had minor deductions). Overall there were 69% As, 9% Bs, 5% Cs, and 17% Ds and Fs. About 21% of the students submitted early, and these early submitters scored much better (97% average) than students submitting on the due day (80%); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

Update on Testing:

  1. For the first part of Problem 2, on test1 and test4 I updated these functions to return the list, which should be unaffected by iterating over it.

  2. For the last part of Problem 2, I was looking for a break statement inside the loop, but on retrospect I was not clear enough on what kind of code is disallowed (no raising exceptions, no manipulating any ListSI object) inside the loop. So, if you did not have break in your code it shows as failing one test: but failing 1 our of 2 tests results on a 1 point problem is only a .5 point deduction, and since the score is rounded up (e.g., 24.5 is rounded to 25) no student lost this point because of not using a break statement.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-J shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem. Row 3 shows the part of the problems in more detail.

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive 15/20*4 = 3 points. Columns K-L show the cumulative score for each Problem. Columns M-O show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • Many students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

This assignment was designed to provide you with a good grounding in the use of iterators and generators (which can be used to implement iterators), and how to write code that uses iter and next directly (using while loop instead of for loop). All these topics will be tested again on the Midterm and In-Lab Exam #2. As with all assignments, you should examine my solutions.

#13: 5/3/18
Program #2 Graded
I have run the automatic batch self-check tests for Program #2 and the grades are now recorded. I used the following batch self-check files (similar to the ones I provided, but with some altered/additional tests). See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 98% and the median was 102%, meaning that most students correctly solved most problems, and over half (93%) of the class correctly solved all the problems (or had minor deductions). Overall there were 93% As, 3% Bs, 1% Cs, and 4% Ds and Fs. About 55% of the students submitted early, and these early submitters scored much better (103% average) than students submitting on the due day (95% average); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later programs.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order); Column B contains an X if we believe the student submitted work on time (for pairs, only the submitting student will show an X, not their partner); Column C shows the extra credit points for early submissions.

Row 2 for Columns D-AA shows how many points the problems were worth. Row 3 shows the number of tests performed for each problem: all were batch-self check tests. Row 4 shows further information about the tests performed in each column.

Rows 5 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 1 of 4 tests on a 4 point problem, he/she would receive 3/4*4 = 3 points. Columns AF-AG show each student's cumulative score, for all the tests in each of the two problems in this assignment. Columns AH-AJ show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 50). Note that these columns are filled in both for submitters and their partners (these are the only columns filled in for partners): a partner should see his/her submitter's line for details.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in some part and therefore failed all that part's tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

  • A few students submitted code that (a) incorrectly named partners -wrong format or wrong UCInetID, or (b) had students listed a partners of multiple submitters, or (c) had both students submitting and listed as partners of submitters. The TAs are authorized to try to understand these problems and help me correct them (but, I will deduct some points for dealing with these problems).

This assignment was designed to provide you with a good grounding in the use of classes and the practice of overloading operators in classes, including a bit of writing iterators. Quiz #4 covers decorators for iterators using generators. All these topics will be tested again on the Midterm and In-Lab Exam #2. As with all assignments, you should examine my solutions.


#12: 4/30/18
Quiz #3 Graded
I have run the automatic batch self-check tests for Quiz #3 and the grades are now recorded. I used the following batch self-check files (similar to the ones I provided, but with some altered/additional tests). See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 93% and the median was 100%, meaning that most students correctly solved most problems, and well over half (79%) of the class correctly solved all the problems (or had minor deductions). Overall there were 78% As, 13% Bs, 2% Cs, and 7% Ds and Fs. About 30% of the students submitted early, and these early submitters scored better (97% average) than students submitting on the due day (92% average); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-N shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem.

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive 15/20*4 = 3 points. Columns O-P show the cumulative score for each Problem. Columns Q-S show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop or just code that took too long).

This assignment was designed to provide you with a good grounding in the use of operator overloading in classes: this includes both standard arithmetic and relational operators, as well as other methods that Python writing calls automatically (e.g., __repr__, __str__, __getitem__, etc). All these topics will be tested again on the Midterm and In-Lab Exam #2. As with all assignments, you should examine my solutions.

In the Time class, some students wrote operators that returned strings instead of Time objects; a few bsc.txt tests fail in such cases.


#11: 4/27/18
In-Lab Programming Exam #1 Graded
I have run the automatic batch self-check tests for In-Lab Exam #1 and the grades are now recorded. See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7.

You can find your solutions (by your Hashed ID), my solution, and the actual bsc.txt files I used to compute grades for this assignment, in the EEE dropbox for this class (see the name ile1studentsolutions.zip); when you test your code with the bsc.txt, you will have to uncomment the code at the start of the script that imports driver and calls driver.driver().

I believe the In-Lab Exams are the best indicator, of all testing instruments, of your ability to program: read specifications and transform them into working code (writing code and debugging it). As I'll say in class, Tolstoy is often quoted (from Anna Karenina) as writing,

"Happy families are all alike; every unhappy family is unhappy in its own way."
My adaptation of this quote is
"High-scoring students are all alike (knowing how to program well); every low-scoring student did poorly in his/her own way: e.g., lack of programming or debugging ability, freezing on the exam, misreading or misunderstanding some problem statements, spending too much time debugging one problem, being ill when taking the exam, arriving late, etc."
So, I understand that there are many possible reasons that students don't do well on In-Lab Exams. If you did poorly, think about why; don't fool yourself.

The spreadsheet computes grades in two ways.

  1. The standard way: the percentage of tests passed for functions 1-5, multiplied by 20 (each problem was worth 20 points), plus 1 extra point for each of the last two problems, only if they passes all tests. Column J computes this number, which is also the same as the rounded value (Column K) and the percentage (Column L)

  2. An alternative way: the percentage of tests passed for functions 1-5, but dropping the lowest score, multiplied by 25, plus 1 extra point for each of the last two problems, only if they passes all tests. In addition, there is a deduction of 10 points for this alternative. Column N computes this number, which is also the same as the rounded value (Column P).
The percentage (Column P) is the largest of column K and O. This is the grade recorded in the grades spreadsheet.

The result was the class average was about 74% (resulting in 1 normalization point) and the median was about 100%. The large skew between these statistics shows that although the majority of students solved all the problems correctly, there were other students who did very poorly, which dragged down the average much more than the median. At the extremes, 50% of the students submitted code in which all five functions passed all batch self-check tests; 12% submitted code in which no functions passed any batch self-check tests (although some of these are from code containing bad imports, syntax errors, and infinite loops).

The approximate distribution of grades on this In-Lab exam is 63% As, 1% Bs, 2% Cs, 7% Ds, and 27% Fs. This U-shaped distribution (90% As and Fs) is common for In-Lab Programming Exams, where we are testing competency/mastery of programming concepts: the ones who attained it scored As (could do everything in the allotted time); the ones who have not scored Fs (solved just a few problems in the allotted time); only 10% of students scored somewhere in-between. FYI, the averages for the different exams was 75% for students in Labs 4-6 (meeting at 10am), 68% for students in Labs 7-9 (meeting at 12noon), and 74% for students in Labs 10-12 (meeting at 2pm). This was the first time I put a 2nd extra credit problem on In-Lab Exam #2, and 19% solved it, scoring 102%, which greatly exceeded my expectations.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • If you submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • If you submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).
The actual batch self-check tests I used for grading were similar to the tests in the script of the exam; but, all produce differents results, so students could not "hard-code" any answers into their functions, hoping to get some correctness points. Often I just changed the names a bit (e.g., Barb to Barbi) which leads to different but equivalent output.

Finally, if students score a higher percentage on their In-Lab Exam #2 (which involves material from the first, as well as Classes, Operator Overloading, and writing Iterators), I will score their In-Lab Exam #1 higher (in the past I have often made the first exam score equal to the second; thereby erasing the first score; other times I have averaged the two). Therefore, even a terrible grade on this exam can have a minimal effect on your final grade if you perform much better on In-Lab Exam #2.


#10: 4/22/18
Quiz #2 Graded
I have run the automatic batch self-check tests for Quiz #2 and the grades are now recorded. I used the following batch self-check files (similar to the ones I provided, but with some altered/additional tests).

See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7.

The class average was about 85% and the median was 96%, meaning that most students correctly solved most problems; over half (61%) of the class correctly solved all the problems (or had minor deductions). Overall there were 64% As, 13% Bs, 3% Cs, and 23% Ds and Fs. About 26% of the students submitted early, and these early submitters scored much better (96% average) than students submitting on the due day (81% average); I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Row 1 for Columns C-J shows how many points the problems were worth. Row 2 shows the number of tests performed for each problem.

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 5 of 20 tests on a 4 point problem, he/she would receive (20-5)/20*4 = 15/20*4 = 3 points. Columns L-N show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in at least one of their functions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass and rerun/regrade the code (but, I will deduct some points for submitting code with an infinite loop).

This assignment was designed to provide you with a good grounding in the use of writing regular expressions and using the re module to write code that processes text using regular expression. All these topics will be tested again on the Midterm. As with all assignments, you should examine my solutions.

#9: 4/20/18
Program #1 Graded
I have run the automatic batch self-check tests for Program #1 and the grades are now recorded. I used the following batch self-check files (similar to the ones I provided, but correcting some confusion relating to the Max/Min line when printing the Corpus).

See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. Note that columns AF-AK show information about the submissions for each student: what days submissions occurred (AF-AH), the total number of submissions (AI), how many submissions were graded (AJ), and how many were not graded (AK). Of 261 students submitting, 20 (8%) had one or more submissions not counted; they submitted more than one on the due date, and/or more than two during the last two days.

The class average was about 88% and the median was 100%, meaning that most students correctly solved most problems, and over half (69%) of the class correctly solved all the problems (or had minor deductions). Overall there were 69% As, 9% Bs, 7% Cs, and 15% Ds and Fs. FYI, last quarter, there were 66% As, 10% Bs, 7% Cs, and 17% Ds and Fs. About 36% of the students submitted early, and these early submitters scored much better (101% average) than students submitting on the due day (71% average). I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later programs.

In the assignment spreadsheet, Column A contains the Hashed IDs of all students (in sorted order); Column B contains an X if we believe the student submitted work on time (for pairs, only the submitting student will show an X, not their partner); Column C shows the extra credit points for early submissions (to get any extra credit points, you had to have all five submissions meet the submission-date critera). If column B or C has a red triangle, hover over it to read its message; sometimes you have to right-click the comment, then select "Edit Comment" to enlarge the comment box to read all of it.

Row 2 for Columns D-V shows how many points the problems were worth. Row 3 shows the number of tests performed for each problem: all were batch-self check tests. Rows 4-5 show further information about the tests performed in each column.

Rows 6 and beyond show the number of failed tests for each submission (a blank indicates no failed tests: equivalent to 0 failed tests). To compute the number of points for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student failed 1 of 4 tests on a 5 point problem, he/she would receive (4-1)/4*5 = 3/4*5 = 3.75 points. Columns W-AA show each student's cumulative score, for all the tests in each of the problems in this assignment. Columns AB-AD show each student's cumulative Score, the score Rounded to an integer (what integer is entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (50). Note that these columns are filled in both for submitters and their partners (these are the only columns filled in for partners): a partner should refer to his/her submitter's line for grading details.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned).

IMPORTANT Information about Student Grades

  • A few students submitted code that had syntax errors and therefore failed all tests for that part: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for not submitting executable code). Also see Announcement #5 below.

  • A few students submitted code that didn't finish executing in their reachable (sometimes other) solutions and therefore failed all its tests: the TAs are authorized to allow you to replace any method body with pass (to avoid the infinite loop) and rerun/regrade the code. But, I will deduct some points for submitting code with an infinite loop: in the future, replace any method body with pass if it causes an infinite loop.

  • A few students submitted code that (a) incorrectly named partners -wrong format or wrong UCInetID, or (b) had students listed a partners of multiple submitters, or (c) had both students submitting and listed as partners of submitters. The TAs are authorized to try to understand these problems and help me correct them (but, I will deduct some points for staff having to deal with these problems). As always, see the TA first.

This assignment was designed to provide you with a good grounding in the use of the standard data structures in Python: list, tuple, set, and dict (and the defaultdict variant). It also included practice iterating overs such structures, writing comprehensions, use of the sorted function and lambda, and other useful/important Python functions. Unlike Quiz #1, the problems were bigger, requiring more interesting algorithms to solve, but still all expressible with a small number of Python language features. All these topics will be tested again on the Midterm and In-Lab Exam #1. As with all assignments, you should examine my solutions.


#8: 4/15/18
Quiz #1 Graded
I have run the automatic batch self-check tests for Quiz #1 (checking correctness) and the Readers/TAs have examined problem 1 and the code (checking requirements: e.g., statements/solution) and the grades are now recorded and posted. I used the following batch self-check file.

See the assignment grades and Grades(zipped .xlsm file) files, whose details are discussed below, in Announcement #7. The class average was about 89% and the median was 92%, meaning that most students correctly solved most problems (65% As), and 34% of the class correctly solved all the problems. Overall there were 65% As, 20% Bs, 5% Cs, and 10% Ds and Fs for those students who submitted work; most of the students who scored near 0 submitted code that we could not run (see the paragraphs below for possible regrading by your TA). FYI, the Winter quarter grades for this quiz were 40% As, 24% Bs, 11% Cs, and 25% Ds and Fs for those students who submitted work.

About 32% of the students submitted early (although there are no extra credit points on quizzes for doing so), and these early submitters scored much better than students submitting on the due day (95% compared to 86%): a difference of 1 full grade (students submitting 2 days early had an average of 95%). I am assuming that some students ran out of time before they finished all the problems, and will plan to get started earlier on later quizzes.

In the assignment grades spreadsheet, Column A contains the ID Hashed of all students (in sorted order) and Column B contains an X if we believe the student submitted work on time. Column C shows deductions for

  • written work submitted late (written work is due at the start of class)
  • not printing a copy of quiz page on which you wrote your answer
Row 1 for Columns D-M shows how many points the problems were worth. Some problems show points in two columns: e.g., Problem #3 has 1 point in Column F (3a/C: produced correct answers according to the batch self-checks) and 1 point in Column G (3a/R: the requirement of 1 return statement, according to the TAs). Any /C column relates to correctness; any /R relates to requirements. Row 2 shows the number of batch self-check tests performed for each problem (for those checked automatically; for the other columns it is just the number of points the problem is worth).

Rows 4 and beyond show the number of failed tests for each student (a blank indicates no failed tests: equivalent to 0 failed tests). IMPORTANT: To compute the number of points you scored for a problem/in a column, compute the percentage of successful tests and multiply it by the number of points the problem is worth. So for example, if a student missed 2 of 6 tests on a 5 point problem, he/she would receive (6-2)/6 * 5 = 3.3 (actually, 3.333...) points. Columns N-P show each student's cumulative Score, the score Rounded to an integer (that integer is the score entered in the Grades spreadsheet) and Percent, based on the number of points the assginment is worth (here 25).

The TAS will distribute the pages with Problem #1 in labs this week only; after that, the papers will be archived in my office. The rubric for this problem was as follows: each part was worth .5 pt.

  1. ALL names (a, b, c) are written inside the module object/oval
  2. ALL names have SQUARE boxes written underneath them
  3. ALL arrows point from "namey things" to "objecty things" and the TAIL of ALL arrows are INSIDE the square box.
  4. ALL "objecty things" appear as ovals
  5. ALL "object things" are correctly labelled: int, str or list
  6. ALL: a points to int(2); AND a points to int(1) and is crossed out; AND b points to int(1)
  7. c points to a "listy thing"
  8. c's "listy thing" has 3 indexes pointing to int(1), an extra "listy thing", and str(abc)
  9. c's "listing thing" in index 1 points to int(1) and is crossed out
  10. the extra "listy thing" points from index 0 to int(1) and index 1 to the "listy thing" c points to
  11. the extra "listy thing" points from index 1 to str(abc) and is crossed out
  12. no crossing arrows
If you lost any points on this problem (most students did) I suggest that you start by comparing your solution to mine.

Students should talk to the TA for their Lab first, if they do not understand why they received the marks they did or dispute any of these marks. The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share.

Students should examine their graded work immediately and get any regrade issues settled as soon as possible (within a week of when the grade is assigned). Show up to lab and settle these issues immediately.

IMPORTANT Information about Student Grades

  • A few students submitted code that extraneous imports or had syntax errors and therefore failed all tests: the TAs are authorized to allow you to fix a few simple syntax errors in the code you submitted and rerun/regrade the code (but, I will deduct some points for submitting unexecutable code). Also see Announcement #5 below.

  • If you submitted an assignment, but the X in column B has the comment TIMEOUT it means that one of your functions contained an infinite loop, and therefore failed all tests: the TAs are authorized to allow you to replace the body of any function by pass and rerun/regrade the code (but, I will deduct some points for not submitting gradable code). Also see Announcement #5 below.
This assignment was designed to provide you with a good grounding in the use of the standard data structures in Python: list, tuple, set, and dict (and the defaultdict variant). It also included practice iterating over such structures, writing comprehensions, and use of the sorted function and lambdas. All these topics will be tested again on the Midterm and In-Lab Exam #1 (along with appearing in Programming Assignment #1 as well). As with all assignments, you should examine my solutions.

#7: 4/9/18
Programming Assignment #0 Graded
The TAs have graded (and I have recorded the grades for) Programming Assignment #0. As with most assignments, there are two files that you should download, unzip, and examine to understand your performance on this assignment, and your cumulative performance in this class.

Both of these files are sorted by Hashed IDs (which are computed from the 8-digit UCI IDs of all the students in the class). To determine your Hashed ID, see Message #6 below.

  • The first file to examine stores the assignment grades, a zipped Excel file that details how each student was graded on this instrument: what marks were given and why. It is sorted by Hashed IDs (column A). Column B contains an X if the student submitted work (later, if you work in pairs, the X will appear only on the Submitter's cell, not in the Partner's cell, although both will receive the same grade). Column C (for Programming Assignments only) shows extra credit points for early submission: 1 point for submitting 24 hours early; 2 points for submitting 48 hours (or more) early; a blank here means no extra credit/early submission points.

    Columns D and beyond show marks for the various parts of the assignment. The last three columns show your Score, the score Rounded to an integer (see the discussion below) and your Percent, based on the number of points the assginment is worth. If a cell contains a comment (those cells with a red-triangle in their upper-right hand corner) you can hover over the cell and you will see the comment that explains why the marks were given: sometimes you must right-click the comment and then enlarge its bounding box to see the full comment.

    Students should talk to the TA who graded a question, if they do not understand why they received the marks they did or to dispute any of these marks. For Programming Assignment #0, the grading was as follows

    Tiehang  : Part A
    Seyyed   : Part B
    Juan     : Part C
    James    : Part D

    The best time to talk with your TA about grades is during one of your Labs, when both student and TA are physically present to examine the submission and the grade, possibly running the solution on a computer they can share. The same goes for talking to other TAs. All TAs can download your work from Checkmate.

  • The second file to examine stores the cumulative Grades(zipped .xlsm file) -also available as a link on course web- unzip it, and then click the tab labeled Spring 2018. This tab records all the grades for all the testing instruments that you submit during the quarter. It is also sorted by Hashed IDs (column A). You will notice that in this spreadsheet all recorded grades are rounded up to integers: so receiving a 27.5 on the first spreadsheet will translate into a 28 recorded on the second one. We will use this same "round-up" process for recording all grades during the quarter.

    On this spreadsheet, columns B-T contain your scores: for the Quizzes (B-I), Programming Assignments (J-O), In-Lab Programming Exams (P-Q), and Written Exams (R and T: I'll discuss S after the Midterm). Columns U-X contain the sums for all these testing instruments. Column Y contains special extra credit points (for example, submitting the faculty/course evaluation at the end of the quarter; more on this then. In fact, because this quareter virtually all students submitted correctly and on time in Checkmate, anyone submitting an assignment received one extra credit point, which is listed here). Column Z-AD contains your cumulative points (Z), your average (AA), your rank in class (AB: 1 means highest-scoring student), and your current grade (AC is the letter, AD is +/- if appropriate).

    You should check this spreadsheet after every assignment is graded to ensure that your score was recorded correctly. Again, students should talk to the TA for their Lab first, if this spreadsheet contains any errors.

IMPORTANT: Scores wil revert to 0, if I do not receive a signed Academic Integrity Contract from you (we are tabulating them this week). Please come by during my office hours as soon as possible if you need to fix this problem.

This assignment was designed to test you on whether you have mastered the basics of using Python in Eclipse, the Eclipse Debugger perspective, and batch-self-check files in the driver.py module (in courselib). It was also designed to see if you could follow instructions and ask questions: more on that below.

The class average was 29 (or about 98%) and the median was 30 (or about 100%). For those students submtting work, there were 91% As, 6% Bs, 1% Cs, and 2% Ds and Fs.

The assignment was not meant to be hard, but it was not trivial either, and there were many opportunities to lose points (and learn from your mistakes). Your work in the Eclipse/Python Integrated Developement Environment (IDE) throughout the quarter will leverage off the understanding and skills that you acquired in this assignment.

Let me talk about what will probably be the most contentious single point of the 1,000 points that this course is worth (thus .1% of the grade) I took off 1 point if you corrected the misspelling Inteprxter (and took off 2 points if you didn't have either spelling: in this second case you obvious failed to meet the specifications because you did not print what was required). When some students hear about this point deduction, their heads explode and they cannot believe that I am taking off a point for correcting what you thought was my mistake. But... I am trying to foster an atmosphere where nothing is taken for granted in the instructions that I give: if anything seems confusing or plain wrong, I should be questioned about it -preferably in public, on a MessageBoard forum- so others can learn if there really is a problem, and if so the correction.

  • Some students did ask me outside of class if they should correct the misspelling, and I told them "no"; some students asked me by email if they should correct the misspelling, and I told them "no"; one student asked on a MessageBoard forum whether they should have corrected the misspelling, and I posted a reply saying that they shouldn't, for all students in the class to see. It is critical for programmers to be sure they know the specifications of the problem they are being asked to solve, otherwise they will solve, test, debug document, etc. the problem incorrectly, and another cycle of development will be needed to fix the misconceptions. The overview lecture included a graph that showed that the later in development a problem is found, the harder/more expensive it is to fix. So if we can find problems at the time we are reading the specification of the problem to solve, that can save us a lot of work/money later.

  • The bottom line is that you are responsible for reading the instructions carefully and reporting any confusion so that I can clear it up (best reported on the MessageBoard forum for Programming Assignments). Of course, you can freely talk to anyone about the problem specifications, just not the code that you write for your solutions. If you make any assumptions (like the node names in Programming Assignment #1 always being one letter long -that is not part of the specification), they might come back later to haunt you (gradewise). When working with a partner, you'll have two pairs of eyes reading the specifications. I am willing to deduct this one painful point at the start of the quarter, from many students, to get across this perspective, and save everyone grading grief during the quarter. I hope you submitted early so the extra credit erased this point loss.

  • I will not intentionally do anything like this on subsequent assignments; but I can certainly be unclear about the specifications (which have lots of details) or even contradict myself from one spot to the next. It it up to you to clear up the confusion, and best to do it on the MessageBoard forums, so I can clear up the problem once for all students.

We deducted 1 point on the demo.py program if your # Submitter line did not perfectly match what was required, including using correct spacing, punctuation, lower-/upper-case letters, etc. Many students lost a point here; ensure that you know what you did wrong so you won't lose points in subsequent submissions.

Also, some students did not carefully read the instructions in the Debugger Perspective document for the quiz part, which required them to change a line in the craps script before running it with the debugger to gather the required information. With this change in your program, we can check your answers for correctness; without it, we cannot check you answers for correctness.

Finally, about 54% of the students submitted the program 2 or more days early; about 19% submitted the program 1 day early. So, about 73% of the students submitted this assignment early. Keep up the good work: you can earn 12 extra points if you turn in every Programming Assignment 2 or more days early (upping your grade by 1.2%): for some students, this boost will be enough to raise their final grade. Over the course of a two week assignment, it will be to everyone's benefit -students and staff alike- if students try to finish and submit early.

IMPORTANT If you believe that we graded your work correct, please examine the files mentioned above first, then contact the TA who graded it, to discuss the issues with him/her. Such a discussion can have only positive outcomes: either he/she will agree with you that you deserve more credit (and, we do want you to receive all the credit that you are due), or you will come to understand the question, program, or solution better and realize why you lost points. This is certainly a win-win situation. Please read my solution and the assignment grades spreadsheet carefully before contacting your TA; ensure that you understand what is the correct answer and what points were deducted from your assignment and why. If there is a problem, your TA will email me a revised summary about your program, and cc a copy to you. I will update the grades spreadsheet as appropriate (it might take a bit of time for all these events to cumulate in a changed grade) and email you.

If you feel there is still an unresolved problem after talking to your TA, please contact me (but always contact your TA first). Also, because of the size of this class, if you have a grading issue, we will consider it only if you bring it to your TAs attention within a week of when I return the materials. This policy is in place to avoid an avanlance of work because of "grade-grubbing" late in the quarter.


#6: 4/2/18
Hashed ID
When we grade assignments, we often distribute/update various spreadsheets with the relevant grading information. These spreadsheets are indexed and sorted by each student's Hashed ID. The course web-page has a Find ID Hashed (grade key) link, right below the Grades(zipped .xlsm file) link, which you can use to retrieve your Hashed ID (or click Find ID Hashed). Use the result it shows when examining any spreadsheets of grades; I suggest that you find this number once, and write it down for future reference. If you are an ACCESS student, this link may not work for you; in this case email me when you submit your first graded work.

#5: 4/2/18
Important:
Submitting Code
without Losing Points
ICS-33 uses software that automatically grades most quizzes and programming assignments; it uses (self-checking) testing cases that we supply with the testing instruments that we distribute (sometimes slight variants). You will learn about these tools in Programming Assignment #0. Here are a few hints to ensure that you will understand the grading process better and minimize your point loss.
  1. Ensure that you submit the code you wrote, not empty files, nor the original files that you downloaded. Be very careful and double-check what you submit to avoid this mistake: if you are not sure that you submitted the correct code, resubmit it. After submitting (the correct file) to Checkmate, ensure that it shows the assignment's status as completely submitted.

  2. If you are submitting with a partner, ensure that the Submitter and Partner lines of the program are correctly specified. The names must appear in the exact format required, with no misspellings nor punctuation errors. The student listed as Submitter must be the one who actually submits the code. See the Programming Assignments web page for the exact form required (and you must follow that exact form, with no misspelling nor punctuation errors).

  3. Ensure that you submit your code on time. We can, and mostly do, ignore any work submitted after the deadline (even by a few minutes). It is a fairness issue for other students who do submit on time. The best strategy is to finish the work and submit it well before the deadline (and get extra credit points): you will learn more too, if you aren't rushing to meet a deadline. To ensure that we will grade something, submit partially complete code ahead of the deadline; then, if you miss the deadline, we will still grade the partially complete code. Be warned: Checkmate can get bogged down if many students all try to submit a few minutes before the due time, so do not wait until the last minute to submit your code.

  4. Ensure that you test your code using the self-checks that we provide and use for grading. By using these self-checks, you will know when your code contains errors that will result in point deductions when we grade it. The actual tests that we will use for grading might be a bit different, but will be similar in form and content: so, think a bit about testing your code beyond the self-checks that we supply. No finite amount of testing can show that code is correct for all inputs.

  5. Ensure that your files...
    1. ...contain no syntax errors.
    2. ...contain only appropriate import statements: typically just the ones provided in the download file(s).
    3. ...contain only functions that execute quickly (typically under a few seconds)

    Any syntax errors, inappropriate import statements, or excessive execution time may cause all self-check tests to fail during automatic grading. For functions that take excessive time, it is best to comment out their bodies, replacing their code with pass, resulting in the function immediately returning None: it will be counted wrong, but doing so will allow other functions to be run and graded for correctness.

    To help avoid inappropriate imports and losing points, ensure that in Python have selected Window | Preferences | PyDev | Editor | Auto Imports and unchecked all boxes (illustrated below) and then clicked Apply following by OK.

After an assignment is graded automatically, the Announcement for it will contain a link to an Excel file that you can examine for detailed information about how your score was computed.

If this information does not match your expectations from you running the assignment's self-checks while developing your code, contact your TA. It is best to meet with your TA during lab hours: he/she can talk to you about your code and run it while you are present, to help resolve the difference. But, if we have to modify your code to grade it properly (see the typical source of problems above), then we will deduct points. I hope that by students carefully writing/submitting their code, these grading anomalies and point deductions will be minimized during the quarter.


#4: 4/2/18
Communication
There are many ways to communicate with me (and other staff and students). Here is a quick overview.
  1. Email: If you send me email, please do it through your UCI email address. Include a well-thought Subject line. Also, please include your full name and the course (ICS-33), and your Lab # (for questions related to grading). I teach many hundreds of students each quarter, often in multiple courses. Providing this information helps me quickly determine the context of your email, so I can better answer it. Finally, when I respond to your email, please do not send a "Thank you" acknowledgement. Such niceties are not necessary for work-related email. For me, it just increases the number of emails that I must read.

Note that for questions that are not specific to you -questions that are relevant to the entire class- it is best to ask them on the appropriate Message Board forum.

  1. Message Board Forum: Post on the forum most closely related to your question. Include a well-thought Title line that clearly identifies the issue you are asking about; doing so helps me and other students who are deciding whether to read your message and the response(s). If you discover the solution to your own question, revisit the Forum and explain (without supplying code) any useful information that you learned that might help other students with the same problem. Avoid a post that says just, "Never mind: I figured it out myself."

  2. Course Email (ics33-S18@classes.uci.edu): Mostly this is for me to use to communicate with all the students in the class. But, there are instances (very rarely) for students to use it: the best example is that if Checkmate appears to be unavailable. Sending a Checkmate down email to this address tells me that it is unavailable, and tells all the other students that (a) it is unavailable and (b) I have been informed it is unavailable. FYI, we rehosted Checkmate on a new computer a few quarters ago, and it is now much more reliable and rarely unavailable, but you should still plan to submit your work early.

#3: 4/2/18
First Lab
I expect students to attend all their scheduiled labs (unless they have already finished the current programming assignment). Programming Assignment #0 is assigned before the first lab of the quarter; so if you have not already finished it, I expect you to attend your first lab and work on it there.

Generally, you can get invaluable help in lab from the TAs and Tutors relating to

  • understaing the specifications of the assignment
  • understanding Python language features
  • understanding how to deubg your Python code
For debugging, don't expect the staff to debug your code for you. Instead expect, them to help you learn how to debug your own code in general, using your current problem/code as a concrete example. One goal of ICS-33 is to make students much more independent programmers and debuggers.

#2: 4/2/18
Install Course Software
All students with computers should download and install the course Software: Java (to run Eclipse), Python, and Eclipse. All three products are available for free on the internet. Students can view instructions for downloading and installing this software by following the Course Software link. If you are using a Mac there are special instructions for you (e.g., Java is already installed)

If you have installed a version of Python prior to 3.6, you should install the current version of Python (and the most up-to-date version of Eclipse as well, which is currently "Oxygen").

Although students can work on their programming assignments on the computers in the UCI labs, I expect students with computers to download and install this software by the end of the first week of the quarter. If you are having difficulty with this task, the TAs and Lab Tutors will help you during the first Lab meeting (or beyond, if necessary: bring your computer to the lab). If you have successfully downloaded and installed this software, please help other students do so too. Finally, you can also use the class MessageBoard Forums to ask questions about installing this software and help other students install it. Installing software is sometimes confusing, but it is a one-time event: do it now.

I strongly suggest that you BACKUP YOUR WORK daily: computers can malfunction, break, or be stolen. Every quarter I hear froma few students who have lost their work because they didn't backup their work; get into the backup habit now. I backup all my ICS-33 materials every day by zipping a folder that has all my ICS-33 materials.


#1: 4/2/18
First Message
Welcome to ICS-33. I am going to post and archive important messages about the class in this announcements web page: each entry will be numbered, dated, and labeled. The entries will appear in reverse chronological order. Whenever you follow the link to this page, scan its top for new announcements; scan downward for older announcements. This message will always appear at the bottom of this file. I will never remove a message from this page

I have already posted some important messages before the start of the quarter. Expect a few new messages to be posted here each week, mostly regarding understanding returned and graded work.

Check this Announcements page, along with your email and the MessageBoard Forums, daily.