CPSC 217: Assignment 4

Due at 4 PM. For assignment due dates see the main schedule on the course webpage. The program must be written and run under python version 3.X.

New Concepts to be applied for the assignment

• 2D lists
• Solving a more challenging and larger problem (although not mandatory going through the "Problem solving" lecture material would help for this assignment).
• If you want credit for your work: Do not use any pre-created functions/methods unless you are given explicit permission to do so.   [Generic list of allowable pre-created code in the form of python libraries] Additional functions allowed for this assignment: len, append

Only new concepts that need to be applied in the assignment are listed, concepts previously applied in other assignments may be needed in the implementation of your solution.

Critical design requirements

All instructions must be enclosed within the body of a function, you must write at least 5 functions (JT's solution to A4 had 9 functions written) of your own. Functions that I have created in the starting code isn't included in the count. The functions you write must be properly implemented. No global variables  may be employed. 

The exceptions to including all code inside the body of a function could include: import statements (not really needed for this assignment), the creation of global constants (e.g. ATTIC = 1), a global debugging flag and the call to the initial start or main function.

• You will be penalized heavily if functions are not used or improperly used.

  • No functions or a single function employed then the max assignment grade = 1.0 grade points
  • Two functions properly implemented then the max assignment grade = 1.5 grade points
  • Three functions properly implemented then the max assignment grade = 2.5 grade points
  • Four functions properly implemented then the max assignment grade = 3.0 grade points
  • In order to qualify as properly implemented the function must include instructions (functionality) that are appropriate to that function (e.g. anything related to the attic should not be implemented in a function that includes functionality for the bedroom) and the functions should not be 'empty' (e.g. it just includes a pass instruction) or a token implementation (e.g. a few output statements or declarations).

• In a similar fashion you will be penalized heavily if you define or use global variables (global constants are okay, if you don't know the difference refer to the "Intro programming" lectures covered at the start of the term).

  • When any global variables (not a debugging flag and not constants) are employed then you will be penalized a full grade point (1.0). To rephrase: This penalty applies if you declare one or more global variable(s).

  • Example:
    location = "bedroom"  #Global declared
    def processBedroom():
        if (location == "bedroom"):  #Global referred to in the function.
            #Etc.

• What happens if you ignore both of these requirements (sufficient/proper use of functions and the prohibition on the use of global variables).
  • If you define no functions or just a single function and your program includes any global variables then you will be awarded no credit for this assignment.
• The function-related & global variable penalties are applied on top of other style penalties but the lowest grade that may be awarded is a GPA of 0 (no negative scores will be awarded).

Contrary to student rumors these penalties are not specified in order to "curve the grades down" or to only allow a certain number of students to pass the course. Besides learning the mechanics of defining and calling functions you need to use them properly. For instances you shouldn't complete a course that teaches you how to write short stories and pen tales that are grammatically correct and may even use metaphorical references and include multiple characters if they include hackneyed metaphors and shallow character development. Because the penalties are quite strict then typically most/all (hopefully the latter) students will implement their solutions in the correct fashion.

Resources:

• You must use this code in order be awarded credit [Starting code]. You can (and really must) change the code in the start() function but you cannot change the code in the functions that initialize the list to the different starting positions. The predefined starting positions are needed for testing. It allows the markers (and you) if your program is producing the correct results at the correct point in time (turn).
• Sample output files
• Although all the examples dealing with lists can help you with the assignment there is [one particular lecture example] that illustrates the difference between list variables and the list it refers to. This point is illustrated by showing the correct and incorrect way to copy a list.

Summary:

You are to implement a text-based biological simulation: Conway's "Game of Life". Given a starting pattern of life forms in the simulation ('biosphere') the program will update the pattern according to new births and deaths that occur during that time period (turn).  Each location (element in a 2D list) in a biosphere either contains: an empty space or a life form ("Critter"). As each turn passes in the simulation a new life form may be born into an empty square or an existing Critter may die off in an occupied location. To get any credit for your submission your program must be able to initialize the two lists using any of the 6 starting patterns and it must display the before/after state of the world with the same appearance as the code provided in the display function.

Initialization of the program

Important grading point: Your program functionality marks will only be awarded if your program produces the same results as these outputs. For example, function "oneEmpty()" starts out empty and shouldnever contain a Critter in the pattern. Function "sixthComplexCases()" will produce a stable pattern of 4 Critters in a square by turn 20. Partial marks will not be awarded if your pattern of Critters is 'close' to the pattern produced my program. In addition you need to correctly and comprehensively document which starting patterns that your program will handle. Both of these requirements (producing the same patterns in your output and documenting which cases that your program correctly handles are necessary to make the marking process reasonable - don't expect the marker to expend time hand tracing code to figure out if things are working). However, providing the results that your program must display is also an advantage for you. You will know if your program is "working or not" based on the pattern match (immediate and continuous feedback about your progress). But looking at the patterns is not a substitute for implementing and employing a debugging mode. The debugging mode can be very useful for helping you determine why and how your program is malfunctioning (if you have good debugging output messages)

The code in the starting program is extremely simple and just initializes the references to the lists ('newWorld' and 'oldWorld') to an empty world and displays the result for these lists. The program that you submit will not do things this way.  The old world  is the state of the biosphere before the birth/death rules have been applied during that turn while the new world is the state after those rules were applied. The starting code does apply those rules, you need to write the code yourself to get credit.

Displaying the state of the world (before and after) during the simulation

Important grading point: As mentioned another requirement to get any credit for your assignment is that the display of the grid must be done using the display() function Even the grid is required because it makes the display of world easier to read and interpret for both you and the marker.

Running the simulation

After initializing the starting positions, the program will simulate the births and deaths of the critters over time on a turn-by-turn basis. The user can either hit <enter> to advance the simulation by another turn, 'q' or 'Q' to end the simulation.  A hidden feature (not displayed as a menu option), the [debug mode] can be toggled by entering 'd' or 'D' when prompted to proceed to another turn.

Rules of births and deaths

The births and deaths of critters is based solely upon the number of neighbors in adjacent/neighboring squares. Each square will have from 3 - 8 neighboring squares (inner squares have 8, outer squares can have 3 at the corners or 5 on the top/bottom/left/right edges). The square where the possibility of a birth or death is being examined is marked with a question mark ? in the examples below.

?		?		?
Bottom right corner		An inner square		Top row

Births (square is currently empty)

A birth can occur in an empty square if that square has exactly 3 neighbors, some (non-exhaustive) examples:

*      * ?       *

*       ?    *   *

Deaths (square currently contains a Critter).

A Critter can die of loneliness if it has no neighbors or only one neighbor.

?

?      *

A Critter can die of overcrowding if it has four or more neighbors (non-exhaustive number of examples below):

*      * ?  *   *

* ? *   * * *

The Critter will continue living if it has 2 or 3 neighbors.

?	*
*	*

Births and deaths will occur simultaneously in the simulation. How do the rules of births and deaths relate to the 10x10 world? Each turn the check for births and deaths must be made in each of the 100 squares with the rules apparently being applied at the same time. Hint for how things appear simultaneous: As mentioned the 'old' world contains the state of the biosphere for that turn before the rules have been applied and the 'new' world will track the after state.

Links to online web-based executable versions of the Game of Life:

• [Using pre-determined starting patterns]
• [The starting pattern may be edited]

Debugging mode

Entering 'd' or 'D' will toggle debugging mode (False becomes True, True becomes False). The flag 'debugOn' will track whether debugging message are to appear or not and by default the mode is 'off'.

When the flag is set to 'True' debugging messages will appear, otherwise they will not:

In addition to grading on whether the above functionality was correctly implemented TAs will also look at documentation and style.

Non-functional assignment requirements (style and documentation).

• Python documentation: contact information (your name, student identification number and tutorial number). This should be specified in the header of the program (very top of your program in the form of Python documentation).
  • Identifying information: All assignments should include contact information (full name, student ID number and tutorial section) at the very top of your program.
  • Program version (dates are an acceptable alternative)
    • Under the version you should specify which assignment features were implemented in that version.
  • Any program limitations or weaknesses.
  • If you don't know how to document a program then refer to the "Intro to programming" section of the course.
  • New documentation requirement starting with A3 and applies to all successive assignments: [Inline documentation] (specified just before each function is defined): list the features of the program that were implemented in a particular function, the return type(s) as well as the type(s) of the arguments.
• Style requirements (-0.1 penalty for each now violation of a category there is no maximum cap on the number of style penalties that may be applied (5 categories of penalties means that a maximum penalty of -0.5 may be applied)
  • Naming conventions: You should employ good naming conventions for identifiers (variables, constants, function names, program file names).
  • Named constants should be used as appropriate (i.e. if they aren't defined and used when they should be then a penalty will be incurred).

  • Yes do it this way!	No. Not this way!
    #Defining 3 named constants LEFT = 0 RIGHT = 1 CENTER = 2 #Using the named constant 'RIGHT' if (silverLockPosition == RIGHT):	if (silverLockPosition == 0): #What does 0 stand for???

  • The program code should have appropriate white space (specified in the "Intro to programming lecture') and alignment (specified throughout the lecture notes).
  • Code is self documenting e.g. Clear expressions (e.g. mathematical, Boolean). Good variable names and the use of named constants are examples of writing self documenting code but specifying clear expressions is important enough to be included in a separate category.
  • Of course if a student implements an extreme case of inefficient code (e.g. multiple loops or branches are used when one will do) then penalties may be applied but this is generally rare.
  • Your program should follow the 5 rules of thumb for designing user friendly software (distilled from Jakob Nielsen's 10 usability heuristics) which were included in the notes on 'Repetition' e.g. good error handling (such as prompts to the user to enter the required information clearly indicate what is required, good error messages should be provided for erroneous input) minimizing the user's memory load, being consistent, providing clearly marked exits & providing feedback as appropriate.
  • Having at least one violation in one of the above general style requirements will result in -0.1 penalty to marking. Multiple violations in one category still results in a single penalty (e.g. 3 bad variable names will still result in a -0.1 penalty). However violations between categories will result in cumulative penalties (e.g. a program that includes poor variable names, messy program layout and poor error handling will receive a -0.3 penalty)

     

• Function specific style requirements (principles of good design for functions) -0.2 penalty will be applied for each of the 3 function specific style requirements that have been violated.
  • Functions are one screen in length (normal screen resolution say ~30 lines max of code (excludes whitespace and documentation).
  • Functions implement one well defined task (Appropriate: processLivingRoomCommands() vs. something that's not appropriate  processlivingRoomRunIntroductionRunConclusion()).
  • Code in one function is not duplicated in another function (not in the notes but this is just common sense that you don't write two functions where there's overlapping code - the overlap should likely be taken out of both functions and moved to another separate function). In some assignments there may appear to be some overlap (e.g. each room displays a menu of options but the specific options displayed will not be identical.
  • Violating any of the function specific style requirements will result in a -0.2 penalty for a violation in each of the 3 categories. E.g. a program that includes a function that exceeds the maximum length and implements two or more tasks would incur a -0.4 penalty.

Reminder of critical style requirements