* * * This outline is constantly updated. Students should consult this page regularly for all information relevant to this course * * *

Instructor

Dr. George Karakostas
ITB/218, ext 26132, Mac address: karakos
Office hours: Mon 4:30-6:30 PM (by email appointment)
 

Course Assistance

Schedule

Term II, 2015/16

Lecture:
F 11:30 - 12:20, Rm. T13/125

Section 1 labs: 
T   12:30 - 14:20,  Rm. BSB/249
F  14:30 - 16:20,  Rm. BSB/249

Section 2 labs: 
M  12:30 - 14:20,  Rm. BSB/249
Th 11:30 - 13:20,  Rm. BSB/249

Corequisites

One of CS 1MD3 or ENG 1D04

Course Objective

The main objective of the course is the study of basic Computer Science concepts such as data representation, recursion, computer architecture, concurrency through programming. The programming language used is Python 3. We will not assume any prior programming experience. We will concentrate more on a hands-on application of CS concepts to formulating, analyzing, and solving simple computational problems such as numerical calculations and data manipulation, than on their formal study (which will be the focus of specialized courses later on in your career through the programme.)

Learning objectives, indicators, and rubrics 

Outline of Topics and Student Assessment (Grading)

The course has three parts: lectures (one per week every Friday), preparatory labs (two hours per week per section, Wednesday or Thursday), and problem solving labs (two hours per week per section every Tuesday). There are also reserved lab hours (see above) to use at your leisure for practicing your skills. The organization of the course is as follows: Every week there is a specific topic covered (roughly corresponding to a textbook chapter) by the W/M lab sessions and the preceding lecture. You are provided with a "lab walk-through" document (see the links below) for the "practice" W/M lab, highlighting the most important (but not all!) issues covered by the corresponding material in the textbook, and providing practice problems for you to try. The lecture is also addressing some of these issues (and possibly more) in more depth. Then, during the following Thursday lab, you will be given a set of problems to do during the allotted time (2 hours); these problems are related to the practice problems you were given in the "walk-through" document, and your grade is going to be determined by how well you do in the Th. problem sets. You are going to get this problem set in class (i.e., not beforehand). The ground rules are as follows:

• Cooperation amongst yourselves is strongly advised (and encouraged) during all times except during the problem solving labs on Thursday; you will work on the latter by yourselves, and each student will have to submit his/her work by the end of the lab session using Avenue. You will not be able to revise/resubmit/complement/alter your work after that time, so please be very careful about submitting your work to the right place in the right time. Of course, the solutions to the problem sets must be your own to count; code from others (including the internet) will be treated as an academic dishonesty case, as described by the university policies.
• You are allowed to use your textbook and your notes anytime, but during the Thursday lab sessions, the textbook and your own notes are the only resources you are allowed to use.
  
• There are some basic rules we will follow in grading your assignments; here are some of those:

1. A solution that doesn't even run automatically, or submitted after leaving the lab, gets 0 credit.
2. A solution that runs but is partially correct gets partial credit (depending on the progress towards a full solution).
3. Providing adequate, concise, and meaningful comments throughout your code is part of the solution grade (i.e., a piece of code that correctly solves a problem without ( or with inadequate) comments will score less than a well-commented piece of code that does the same). 

• Attendance: Attendance will be taken for all lab sessions (both practice and problem solving ones) at the beginning of the lab. In order for your problem solutions during a Th. lab to count 100%, you must have attended the previous W/M practice lab. If you submit your solutions on Th. but you have missed the previous W/M practice lab, you'll get 50% credit. Attendance is not required for the lectures. 
  
• There is a final project (which you can find below) that will occupy the last labs of the term; you can start working on it as soon (or work as often) as you like; again, the code you produce must be your own, without any collaboration with sources either internal or external to the class; but you are allowed (in fact, encouraged) to consult with the instructor during the development of your project.
  
• The sequence of topics covered, together with the corresponding "walk-through"'s and their grade weights, is as follows:

1. Fr. 8, Th/F 7-8/1, M/T 11-12/1 (grade weight: 2%):
   Introduction to programming with Python (Read: Chapter 1, Appendix B). Walk-through 1
2. Fr. 15, Th/F 14-15/1, M/T 18-19/1 (grade weight: 5%):
   Writing simple programs (Read: Chapter 2). Walk-through 2
3. Fr. 22/1, Th/F 21-22/1, M/T 25-26/1 (grade weight: 8%): 
   Computing with numbers (Read: Chapter 3). Walk-through 3
4. Fr. 29/1, Th/F 28-29/1, M/T 1-2/2 (grade weight: 10%):
   Sequences: strings, lists, and files (Read: Chapter 5, 11.1-11.3 from Chapter 11). Walk-through 4
5. Fr. 5/2, Th/F 4-5/2, M/T 8-9/2  (grade weight: 10%):
   Decision structures (Read: Chapter 6). Walk-through 5
6. Fr 12/2, Th/F 11-12/2, M/T 22-23/2 (grade weight: 10%):
   Functions (Read: Chapter 7, 8.1-8.2 from Chapter 8). Walk-through 6
7. Fr 26/2, Th/F 25-26/2, M/T 29/2-1/3 (grade weight: 10%):
   Loop structures and Booleans (Read: Chapter 8). Walk-through 7
8. Fr 4/3, Th/F 3-4/3, M/T 7-8/3 (grade weight: 10%):
   Simulation as an example of more complex programs (Read: Chapter 9). Walk-through 8
9. Fr 11/3, Th/F 10-11/3, M/T 14-15/3 (grade weight: 10%):
   Defining classes and using objects (Read: 10.1-10.5 from Chapter 10). Walk-through 9
10. Fr 18/3, Th/F 17-18/3, M/T 21-22/3 (grade weight: 10%):
    Algorithms and recursion (Read: Chapter 13). Walk-through 10
11. From Th 24/3 until Fr 8/4 (grade weight: 15%):
    Project (Due by the last lab session of Fr 8/4) 

• Do the simple things: attend the labs, do all problem sets, use your lab time as much as you can, use the instructor's and the TA's time as much as you can, write good comments in your code, test your code as much as possible before submitting it, submit it correctly and in time, etc. In other words, follow all the straight-forward recommendations above. You would be surprised by how many people overlook such simple things (e.g., forgetting to submit a problem solution altogether).
• Practice, practice, and then practice some more: Just like learning to play the piano, the more you practice a skill the better you become at it. I.e., the more programming you do, the easier it becomes, the more fluent you become in it, the better programmer you become, until there comes a point where no programming exercise/problem/project/assignment scares you anymore. You are probably very far away from this level of competency right now; it's our goal in this course to bring you much closer. OK, so far so good; this is the standard pep-talk one gets (or gives) in a programming course. Why should we believe it? Anything more concrete? Well, read on.
• The cure to all stage (or programming) fright: As stated above, the worst that can happen to you is to "frieze" during a problem solving session (either at the very beginning, when you encounter a problem for the first time, or in the middle of your solution, when you are stuck at a particular point). There is only one cure for this, really: been there, done that. It is not possible to frieze when faced with an issue you have already encountered and solved before. So, do the practice problems in the "walk-through"'s. They have been designed after the problem sets were designed, and with the latter in mind. This doesn't mean that the problem sets contain practice problems; they don't. But they cover the same material, and mostly the same sticky points. And if they are not exactly the same, they are similar. So, even after you do the practice problems, play with them a bit: start thinking about what variations may show up as actual problem sets, and whether you can deal with variations; make sure you can deal with them (by doing some coding). Which leads us to the next point...
• Experiment: Don't be afraid that if you write the wrong programming statement the computer will blow up (it won't) or that you'll be severely disciplined (you won't). So, try things out, no matter how crazy they may seem. But even for simple things, people forget that they can try them out. For example, suppose you are stuck because you don't remember whether '//' is an integer or a floating point division. You can either spend 5 minutes searching the textbook OR you can try '4//2' to see whether it returns an int or a float in 2 secs. Of course, in order to come up with this 'experiment', you must first know what an 'int' or a 'float' is. Which brings us to the next point...
• Study: No matter how good an 'experimentalist' you are, loads of time has been lost re-inventing the wheel. Studying the textbook and any other resources you can get your hands on cannot be replaced by any amount of experimentation, because these are sources of condensed wisdom by many, many, MANY programmers that came before you. Take advantage of them! Always try to study with a Python interpreter open next to you; once you verify something you've just read about, it sticks with you, and the textbook puts it in the more general context of what we are trying to do. So you are able to see the individual trees AND the forest.
• The devil is in the details: This is really the source of most consternation in a programmers life: you know that something can be done, but which is this little instruction you can use to do it? Or, I got this weird error message and a pointer to my code; what's really going on with this particular character? Programming is an art of precision; you either get something (whatever small) right or not at all. It is not enough to "sort-of" know how to solve a problem, or "have an idea", or know "the general gist". Can you program it and make it run? If yes, then indeed, you know how to do it.
  
• Getting lost in the details: When you are trying to solve a problem, it is very easy to lose sight of what actually you are trying to do; instead, you are misguided by some minor detail towards directions that have nothing to do with the big picture. The solution to this problem is to start not from the details, but from the big picture itself: before you plunge on your keyboard to write code, put it aside, pick up your notepad and your pen and design your solution on paper conceptually. The textbook actually follows a very easy step-by-step design approach that takes you from the informal problem description to the final code; it would be great if you can imitate it. 
  
• Two common mistakes: Mistake No. 1: "Oh, I've programmed in Python for 2 years in high school. Boooring!" Confidence is a good thing, overconfidence is not. Even if you believe that you already know the material, see it as a challenge; assume that this course is trying to get you in some tiny detail so that it will destroy your GPA just off the bat for ever and ever. So pay attention to the textbook; do the "walk-through"'s; if a problems seems too easy, make it more challenging yourself. Mistake No 2: "Who needs the textbook, when we have the "walk-through"'s?" A common mistake students make (in many courses) is the notion of "focusing on the key points", i.e., they would prefer to read a 10-page summary of a 3-month 600-pages-long-textbook course to the actual course material. Just as nobody would hire a piano player who has learned to play only with the black keys, nobody would hire someone whose knowledge of a subject is 15 printed pages long. It is mathematically impossible to fit 600 pages in 15 (ask your ECE friends for a proof based on Information Theory). So, just coming in the lab for a couple of hours to do the "walk-through" and (maybe) a couple of practice problems is not enough. The "walk-through"s are designed to just guide you in your study and experiments; they are not a replacement or summary of the textbook.      
• Organize your time: Probably you already know this by now, but time management can make or break your student career. For this course, I would propose the following time organization: First, study the textbook material relevant to the weekly topic before the "walk-through" and the W/Th lab session; do it with a Python interpreter open nearby. Second, come to the W/Th lab session to do the "walk-through"; most likely you'll not have time to do all practice problems, so continue with it after the lab, at your own pace. Third, come to the lecture on Friday; it may point out things that you've missed, and you get the chance to ask about things you've not understood very well. Fourth, by now you have most probably finished with the practice problems, and with the questions/exercises from the textbook; so try to do some variations that may seem like good problems for Tue. Fifth, come and do the problem set on Tue. Notice that the actually hard part is to do the book reading before the corresponding W/Th lab; to achieve this, you probably want to be one week ahead of time in the topics we cover; it sounds brutal, but the initial week (when there is no problem set) gives you a head start.     
  

• Know the notions of variables and expressions
  
• Compute with numbers
  
• Manipulate sequences (Strings, Lists, and Files)
  
• Define functions and use call-by-value or call-by-reference
  
• Use decision structures and boolean expressions
  
• Use definite and indefinite loops
  
• Define classes and use objects in OOP
  
• Use recursion in algorithms
  
• Apply all basic concepts to build a more complex project

Resources

To read PDF files, you'll need the Adobe Reader, which is here.

Textbook: "Python Programming: An introduction to Computer Science", 2nd ed., by J. Zelle.

Avenue: Submissions, code from the book, "walk-through"'s etc. are done and can be found in the Avenue section for the course. 

Other resources: Python is so commonly used that there are very many books and electronic resources for all levels of programmers, from the beginner to the very advanced. There are many excellent (text)books and web sites/tutorials that can be used for studying Python. Here I give only a couple of pointers you may find interesting and useful, but don't feel discouraged from creating your own "programming (e)library".

• The first place any novice Python programmer goes to usually is the Python tutorial by the Python Software Foundation: http://docs.python.org/3.3/tutorial/
  
• More generally, the Python Software Foundation home page is THE basic source for anything Python (e.g., build-in function descriptions, libraries, etc.): http://docs.python.org/release/3.0.1/index.html
• Even more generally, here is the home page for the Python language: http://www.python.org
• A great collection of Python resources can be found in the nettus+ Python page: http://net.tutsplus.com/tutorials/the-best-way-to-learn-python
• John M. Zelle, the author of the textbook, maintains a site for the book where you can find great material related to the book (for example, the code in the book, or lecture slides): http://mcsp.wartburg.edu/zelle/python/ppics2/index.html
  

Academic Dishonesty

"Academic dishonesty consists of misrepresentation by deception or by other
fraudulent means and can result in serious consequences, e.g. the grade of
zero on an assignment, loss of credit with a notation on the transcript
(notation reads:  "Grade of F assigned for academic dishonesty"), and/or
suspension or expulsion from the university.

It is your responsibility to understand what constitutes academic
dishonesty.  For information on the various kinds of academic dishonesty
please refer to the Academic Integrity Policy, specifically Appendix 3,
located at http://www.mcmaster.ca/senate/academic/ac_integrity.htm

The following illustrates only three forms of academic dishonesty:
1.    Plagiarism, e.g. the submission of work that is not one's own or for which other credit has been obtained.  (e.g. submitting a copy of someone else's writeup for an assignment)
2.    Improper collaboration in group work. (e.g. collaboration between groups in an assignment)
3.    Copying or using unauthorized aids in tests and examinations."

 

Faculty Notices

"The Faculty of Engineering is concerned with ensuring an environment that is free of all discrimination.  If there is a problem, individuals are reminded that they should contact the Department Chair, the Sexual Harrassment Officer or the Human Rights Consultant, as the problem occurs."
  
"The instructor and university reserve the right to modify elements of the course during the term. The university may change the dates and deadlines for any or all courses in extreme circumstances. If either type of modification becomes necessary, reasonable notice and communication with the students will be given with explanation and the opportunity to comment on changes. It is the responsibility of the student to check their McMaster email and course websites weekly during the term and to note any changes."