ENAS 130 Fall 2021 Intro. to Computing for Eng. and Sci. Classes, arrays, graphics, loops, conditionals, I/O, etc.
INSTRUCTIONS TO CANDIDATES
ANSWER ALL QUESTIONS
I need to complete a project as defined by the pdf file included. It is due on 12/02 at 11:59pm. Thanks.
ENAS 130 Fall 2021
Intro. to Computing for Eng. and Sci. Dr. B.A.V
Classes, arrays, graphics, loops, conditionals, I/O, etc.
Submission directions: As usual, upload only your source code to Canvas. Name your file as shown.
• Problem 1: pset9_prob1_Lastname_Firstname.cpp
General advice: Start this pset as early as possible! It is considerably more complicated than our previous
psets. It will take longer to understand the requirements, longer to write the code, and longer to debug
it. Please start this pset much earlier than you would normally start a pset for this course.
Note about how we compute your pset average: Because this pset is more complicated, the total
possible score is 200, which means that the total possible number of pset points for the semester is 1000.
Therefore, we will use the following formula to compute your pset average:
pset average =
Remember that half of your course grade comes from your psets; see page 2 of the syllabus.
Late submission policy for this pset: For every 8 hours (or portion thereof) that you submit your pset
late, your score will drop by 5 points out of 200. Psets that are submitted more than 48 hours late will
not be accepted.
Problem 1 (200 points)
Write a large part of a C++ code (the rest of it will be provided) to implement the Game of Life‡
in 1970 by John Horton Conway, a British mathematician. The “game” is actually a mathematical model
of births and deaths in a collection of one-celled living organisms. In the standard version of the game,
which is what you will implement, the organisms live in a two-dimensional universe.
The universe and the organisms
Your code will represent the universe as a one-dimensional integer array named array. The total
number of entries in array is equal to width × height, where the width and height are set based
on valuesinput by the user; assume that these inputs are positive. Furthermore, the edges of the universe
may wrap around (wrap = 1) or may not wrap around (wrap = 0), depending on a choice made by
the user. “Wrap around” means that the top edge of the universe is considered adjacent to the bottom
edge, and the right edge of the universe is considered adjacent to the left edge.
In the universe, there are one-celled organisms. A value of 1 for an array entry signifies a live cell in the
corresponding location in the universe, while a value of 0 signifies a dead cell. The current status of the
universe will be displayed in a graphics window.
See, for example, Conway’s Game of Life at https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life.
Setting up the graphics window and Generation 0
Your code will open a graphics window whose aspect ratio is determined by width and height; in other
words, when calling ploton, the ratio of the width (in pixels) and height (in pixels) of the graphics
window will be equal to the ratio of width and height. To set the initial configuration of live and dead
cells, which is also known as Generation 0, the user can either choose to read in a configuration from a
file or to input a configuration interactively via the mouse.
To do the latter, the user will click and drag the mouse in a manner similar to that seen in the
mouseInteractions sample code (seen in Lecture 20 on 11/15/21 M), coloring in squares in the
graphics window (accomplished via drawRect). Each colored square will represent a live cell. Clicking
on a colored square will reset it to white (i.e., making it a dead cell), allowing the user to correct any
mistakes. The colored squares will all be the same color, the choice of which is up to the user. The size
of each square is controlled by the user as well, and so is the speed at which the simulation will progress.
When satisfied with the initial configuration, the user will right-click to start the simulation.
How successive generations are determined
Each cell has eight neighbors, just as a square on a piece of graph paper is surrounded by eight neighboring
squares. Cells survive, die, or become alive during successive generations according to the following
“genetic laws” that depend on the number of live neighbors that a cell has.
Survival: Any live cell with two or three live neighbors survives (stays alive in the next
Death (1st way): Any live cell with fewer than two live neighbors dies (becomes a dead cell in the next
generation), as if from isolation.
Death (2nd way): Any live cell with more than three live neighbors dies (becomes a dead cell in the next
generation), as if by overcrowding.
Birth: Any dead cell with exactly three live neighbors becomes a live cell in the next
generation, as if by reproduction.
It is important to understand that all births and deaths occur simultaneously. Together they constitute a
single generation in the complete life history of the initial configuration. Therefore, after your code
determines the next generation (i.e, the next configuration of live and dead cells in the universe), your
code will update the appearance of the graphics window accordingly. Your code will then determine the
generation after that one and update the graphics window again, etc.
There are many interesting patterns that can develop as the simulation progresses, some of which are
well known. See the Wikipedia page given in the footnote on page 1 for some of the more common
patterns. A few sample input files have been provided in the Pset 9 assignment on Canvas. Your code
must be able to read one of these files and use it to set the initial configuration, if the user so desires.
Stopping the simulation
Once the simulation has started, the user can right-click again to stop it. Before your code finishes, it will
give the user the option to save the initial configuration to a file. A saved file can then be used to set the
initial configuration during a later run of the code.
More implementation details
The code lives in several files, all of which are provided in the Pset 9 assignment on Canvas. Some of these
files are the familiar graphics-related files that we’ve already seen in the animateSquare and
mouseInteractions sample codes in Lecture 20. (These graphics-related files are similar to, but not
the same as, files that were part of the plotFunction sample code earlier in the semester.) Other files
are as follows:
gameOfLife.cpp: The main program, which has been written for you. Do not change it.
life.h: The declaration section for the Universe class (i.e., data members and member
function prototypes), which has been written for you. Do not change it.
life.cpp: The implementation section for the Universe class, which you will have to write.
As you can see, you will be writing the definitions of the member functions of the Universe class, which
you will put in life.cpp. Do not make any changes in any other files. Before uploading your
life.cpp file to Canvas, please rename it to pset9_prob1_Lastname_Firstname.cpp.
Input files (also known as configuration files)
As mentioned earlier, the user can choose to read in an initial configuration from a file; also, when the
simulation ends, the user can choose to write the initial configuration to a file. The file format for storing
a configuration is as follows.
• The first line of the file contains one integer, which is the width of the universe.
• The second line contains one integer, which is the height of the universe.
• The third line contains one integer, which is the wrap parameter.
• The rest of the file consists of height lines, each of which contains width numbers (0s and 1s)
separated by spaces. For example, if height=6 and width=11, then the rest of the file consists of
6 lines, each of which contains 11 numbers separated by spaces. A value of 0 represents a dead cell,
and a value of 1 represents a live cell.
Three sample configuration files have been provided.
• glider_nowrap.dat: This file contains a glider — a configuration that will “glide” in the direction
in which it is aimed. You can see a moving glider one-third of the way down the Wikipedia page.
When the glider reaches the edge of the universe, it turns into a 2×2 block. This file is useful for testing
the basic parts of your code, particularly the wrap=0 case.
• glider_wrap.dat: This file contains the same glider as the previous file, but the wrap parameter
is now set to 1. As a result, when the glider exits one edge of the universe, it reappears at the opposite
edge. This file is useful for testing code related to the wrap=1 case.
• gosper.dat: This file contains a “Gosper glider gun”; see the information two-fifths of the way
down the Wikipedia page. It is a more ambitious test of the wrap=0 portion of your code. Wait to
try it until after your code can successfully handle glider_nowrap.dat.
The locations of the 1s that you see when viewing any input file using a
text editor (but NOT the file previewer on Canvas, which sometimes
ignores carriage returns) are the same locations where colored squares
should appear in the graphics window when your code reads in that file.
For example, glider_nowrap.dat and glider_wrap.dat
should both produce the initial configuration shown to the right.
You do not have much control over the terminal I/O, because most of it occurs in the main program (i.e.,
in gameOfLife.cpp). In your completed version of life.cpp, the only times you will use cout are
when you print messages telling the user that memory for an array can’t be allocated or that a specified
file can’t be opened. You will never use cin.
Here is an example of what the terminal I/O will look like, prior to when the user right-clicks to start the
simulation. This example corresponds to the graphics window example given above. User inputs are
shown in blue.
Enter an integer representing color,
where 0=grey, 1=red, 2=green, and 3=blue:
Enter an integer between 1 (slow) and 10 (fast):
Enter an integer between 10 (small) and 30 (large) for the cell size:
Read in the universe setup from a file? (y/n)
Enter the name of the file (or drag the file here):
Click or drag the mouse in the window to enter live cells.
Click a live cell to delete it.
Right-click to start the simulation.
Hints to help you get started
Begin by writing a “stub” for each member function. A stub consists of a function header, followed by a
skeletal function body (i.e., the minimal amount of function code that will enable the overall code to
compile). For example, a stub for the default constructor could be
// Body of default constructor will go here eventually
and a stub for the three-argument constructor could be
Universe::Universe(int widthInput, int heightInput, int wrapInput)
// Body of three-argument constructor will go here eventually
Then write and debug the member functions one or two at a time. The order in which you should tackle
the functions will roughly correspond to the order in which they are called in the main program. Note
that you will need to wait to work on display() and setup() until after we cover the
animateSquare sample code (on 11/15/21 M) and the mouseInteractions sample code (also on
11/15/21 M), but you can work on all other functions before then. Be aware that one of the most timeconsuming functions to write will be the neighbors function.
Hints relating to the graphics window
It’s been a while since we wrote any codes that involved graphics in Qt. Take look at Lecture 07, Slides 15
and 16, for some tips for codes with graphics.
As mentioned near the top of page 2, the aspect ratio of the graphics window will mimic that of the Game
of Life universe. The simplest way to accomplish this window sizing is to set the width of the graphics
window (in pixels) to globalCellSize*width and to set the height of the graphics window (in pixels)
to globalCellSize*height. You will force these settings to occur when you issue ploton.
When calling scalx and scaly, place the origin of the graphics window in the upper left corner, with
the positive 𝑥 axis pointing to the right (as usual) and the positive 𝑦 axis pointing downward, exactly as
was the default in imagesc in MATLAB. That way, when you look at the pattern of colored squares and
blank squares in the window, they will correspond to the appearance of the 1s and 0s in array if we
were to treat array as being two-dimensional. For example, the 1st row of array (in which the row
index is 0) will correspond to the top row of squares in the window; the 2nd row of array (in which the
row index is 1) will correspond to the row of squares below the top row in the window; and so on.
Also, use width and height as some of the arguments in your calls to scalx and scaly, so that the
values returned by mouse clicks can be used to refer to array elements. Then, for any point in the graphics
window having coordinates (𝑥, 𝑦), the value of 𝑥 (or at least, the value when the float x is converted
to an int) is the column index of the corresponding element in array, and the value of 𝑦 (when
converted to an int) is the row index.
Do not expect the graphics window to close itself after the user right-clicks to end the simulation. Unless
the user closes the graphics window manually (by clicking on “X” in the top part of the window frame),
the terminal window may hang. If you see these behaviors, don’t worry about them; they are normal.
As you know, the purpose of the sample codes is to see examples of how to use the syntax of various
commands, and, more broadly, how to accomplish certain common coding tasks. Here are a few sample
codes you may find useful to refer to while working on this pset.
• classDataset_with_copyOfMyData_V2.cpp: This sample code from Lecture 20 on
11/15/21 M has a default constructor (for a class whose member variables included a pointer to an
array), a destructor to free some dynamically allocated memory, and an operator function that
overloaded =. The code also dynamically allocated an array after reading in information from a file.
• animateSquare.cpp: This sample code from Lecture 20 on 11/15/21 M uses clear,
drawRect, and updateImage to update an image in the graphics window.
• mouseInteractions.cpp: This sample code from Lecture 20 on 11/15/21 M alters an image in
the graphics window based on input from the mouse. The code also stops accepting input after the
user right-clicks the mouse.
• fileIO.cpp: This sample code from Lecture 19 on 11/10/21 W reads in information from a file and
writes information to another file.
• matrixAlloc.c: This sample code from Lecture 10 on 10/04/21 M treats a one-dimensional array
as a two-dimensional array; in other words, it accesses elements of a one-dimensional array using two
indices: a row index and a column index.
Demonstration of the Game of Life, etc.
Lecture 21 on 11/17/21 W will include a demonstration so that you can see how the graphics portion of
the code should behave. This lecture will also include a brief review of matrixAlloc.c (because we
saw it so long ago), as well as an opportunity for general Q&A about the pset requirements, strategies,
etc. It is hoped that by the time Lecture 21 occurs, you will have already started working on your code;
otherwise,trying to come up with questions may be difficult. Of course, any questions that are too specific
to your own code should be more appropriately asked during office hours or help sessions, not during the
Drop-in help sessions and office hours
Pset 9 is longer and more difficult than previous psets, so the drop-in help session and office hour schedule
has been expanded. Please see our course’s Canvas site for more information.
• The only file you are allowed to change is life.cpp.
• Start this pset as early as possible!
• The collaboration policy appears on page 4 of the syllabus. Please reread it before starting to work
on this pset.
(150 points) Code compiles and runs without error for the input files mentioned on page 3. Code uses C++
syntax instead of equivalent C syntax. For example, code performs I/O by using streams along
with the extraction (>>) and insertion (<<) operators. Code uses new instead of malloc,
delete instead of free, nullptr instead of NULL, etc.
(25 points) Code runs without error for other inputs.
(25 points) Code includes reasonable comments and good coding style.
Q1. I opened all of the code-related files in Qt, and I noticed that Qt shows errors on line 3 of
moregraphics.h and on line 3 of moregraphicswindow.h. What should I do?
A1. Just ignore those messages from Qt. The code will still compile and run properly, even with the
“errors” — which actually aren’t errors at all!
Q2. I’ve looked at gameOfLife.cpp, and I see that there is apparently a Universe class, but I have
no idea what the member functions should do. How am I supposed to figure out this information?
A2. Take a look at the life.h header file. It contains the declaration section for the Universe class.
The comments next to each function prototype state what each function should do.
Q3. Where can I find out more about the argument list of drawRect?
A3. Read the relevant comments in the moregraphics.h header file.
Q4. I’ve written the neighbors member function, but it contains a huge number of if statements. Is
this way acceptable? Is there a simpler way, especially for the wrap = 1 case?
A4. There is a simpler way that involves using the modulo operator %. However, if you can’t figure out
the relevance of %, then it is perfectly acceptable to write the neighbors function using many if
Q5. When I run my code, my graphics window just keeps alternating between two apparently unrelated
configurations. Where should I look for a bug?
A5. The problem is likely in your << member function that applies the genetic laws given in the middle of
page 2. Make sure you’re setting the values of cells in the next generation, not the current generation.
Also, for any dead cells in the current generation that need to remain dead, make sure you explicitly
set those cells to be dead in the next generation; it won’t happen automatically. The same is true for
any live cells in the current generation that need to remain live.
Q6. I’m seeing a strange behavior when I run my code. Here is the situation. My graphics window’s height
(or width) occupies most of the height (or width) of my laptop screen. When I click in the graphics
window to turn individual cells on or off (while setting up the universe), the colored square that shows
up after each mouse click is located somewhere above or to the right of where I just clicked, instead of
being adjacent to where I clicked. Furthermore, each colored square looks more like a rectangle than
a square. What could be causing this strange behavior?
A6. It’s very likely that you’ve called ploton with arguments that are too large for your laptop screen.
For example, if your screen is 1600 pixels high, and you’ve chosen a cell size of 30 and a universe that
is 50 cells high, then ploton will be attempting to create a graphics window of height 1500 pixels.
That sounds acceptable, since 1500 is less than 1600. However, most OSs will prevent any windows
from overlapping the taskbar at the bottom of the screen, and additional pixels will be occupied by
the “title bar” of the graphics window. The usable height of your screen is therefore less than 1600
pixels, and probably less than 1500 pixels, too. The lesson is that it’s not a good idea to call ploton
with height or width arguments that get too close to the number of pixels in the height or width of
your screen. Lastly, note that your code does not necessarily have a bug! The way to fix the “problem”
is to choose a smaller cell size when running your code.
Q7. I have a Mac. I ran my code, and at the end of the run, I chose to write the initial configuration to a
file. Now I can’t find the file, even though it should be in the build folder. What’s going on?
A7. For an unknown reason, some Macs hide the output file. The next time you run your code and it asks
you to type the filename to which you want to save the initial configuration, type the full file path
instead of just the filename. Then your file will show up in the folder that you’ve specified, which
does not necessarily need to be the build folder.
. Introgramming & Unix Fall 2018, CRN 44882, Oakland University Homework Assignment 6 - Using Arrays and Functions in C
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
. The standard path finding involves finding the (shortest) path from an origin to a destination, typically on a map. This is an
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
. Develop a program to emulate a purchase transaction at a retail store. This program will have two classes, a LineItem class and a Transaction class. The LineItem class will represent an individual
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
. SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:
Introduction - the SeaPort Project series
For this set of projects for the course, we wish to simulate some of the aspects of a number of
. Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:
Introduction - the SeaPort Project series
For this set of projects for the course, we wish to simulate some of the aspects of a number of