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.

 

1

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 =

1

10∑pset𝑖

9

𝑖=1

.

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‡

, developed

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.

2

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

generation).

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.

3

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.

(continued)

4

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.

Terminal I/O

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:

3

Enter an integer between 1 (slow) and 10 (fast):

8

Enter an integer between 10 (small) and 30 (large) for the cell size:

15

Read in the universe setup from a file? (y/n)

y

Enter the name of the file (or drag the file here):

glider_nowrap.dat

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

Universe::Universe()

{

 // 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

}

5

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.

Other hints

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.

6

• 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

general Q&A.

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.

Final reminders

• 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.

FAQs

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!

(continued)

7

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

statements.

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.

Attachments:

Related Questions

. 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:

1 Project 1 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:

1 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