Name:
Andrew ID:
Collaborated with:

On this homework, you can collaborate with your classmates, but you must identify their names above, and you must submit your own homework as an knitted HTML file on Canvas, by Monday August 5 at 10pm, next week.

Introduction to percolation

In this homework, we’ll be coding a series of functions to investigate percolation via simulation. We’ll spend this section to discuss the problem and setup. You can read related literature on this topic at Wikipedia, but we’ll be working with a simplified setting for this homework. As a word of caution, this is a coding heavy homework (as opposed to statistical), so be prepared to spend a lot of time debugging and testing.

Here’s the idea. Imagine you have a square board (10 by 10 squares) like the left board show below. This board consist of white “open” squares and black “blocked” squares. We are interested in knowing (abstractly) if we “pour water” from the top of the matrix, does the water “leak” from the bottom of the matrix. This is demonstrated in the right board. (Don’t worry, we’ll explain all the necessary specifics later.) You can think of this as the following: we indefinitely keep pouring water into each white square in the top row at the same time, and water runs through the board by spreading to any adjacent white square (left, right, top, and bottom). We keep pouring water until all the possibly-flooded squares are flooded. These are the blue squares shown below in the right board. Once we’re done, we see if the water reached any of the open squares in the bottom row of the board (i.e., are there any blue squares in the bottom row?). If so, we say the board “percolates”. Otherwise, it does not percolate. In the figure shown below, the displayed board percolates (left is the original board, and right is the percolated board).

However, not all boards percolate. Consider the next board, shown below. Once again, we show the initial board on the left, and we start pouring water, resulting in the board on the right.

Now imagine we had a way to randomly generate these boards. We would like to see if there are certain types of randomly-generated boards that more likely to percolate. We’ll formalize this task in this homework.

So what are the goals of this homework? We will be developing a package with version control and github connection. This package will encapsulate a set of functions related to a new object, called board. While developing our package, we will be writing the following functions: generate_board_mat() will generate a random board (matrix version) with white “open” squares and black “blocked” squares. is_valid() will check whether or not a given board matrix is correctly formatted. plot.board() will plot the board, similar to the four boards shown above. The last two functions contribute the challenges to this homework: percolate.board(), which determines whether or not a board percolates, and read_board() reads in a text file that specifies many boards. Note that plot.board() and percolate.board() will be methods of the class.

We will not give you explicit guidance on how to debug and test throughout most of this homework, but the concepts and tools you’ve learned in lecture will certainly be beneficial as you write and try out your code.

Note: The grading of this homework with depend mainly on whether or not you pass the test cases provided. Your implementation of percolate.board() and read_boards() might look quite different from another classmates, but be you sure that your code passes the tests if you want full credit!

Making a package and using version control

As you will be learning version control and connection to github during Wednesday’s lecture and making packages but you should start this assignment early in the week, I provide 3 ways to approach this homework (conditional on your experience and willingness to read future lectures). I recommend that you try to at least start with Approach 2 if you have some knowledge about Github.

Approach 1 (Base Approach):

Start writing all you code into this homework .Rmd file as usual. As long as the code you write well documented the you can transfer your code to a package with version control at the very end (this is less prefered in terms of using version control - but is fine for now). At the very end of the assignment will be guidance on how to create your package with version control. Note: the “Approach 2/3” comments throught this document can also aid this this endeavor.

In this approach - it is very important that all functions and tests you write deal well with the “local” vs “global” paradigm - that is, don’t assume more things are in the global environment than you need.

Approach 2 (Github start):

Using the guide in Wednesday’s Lecture, create a new github public repository please call it percolate and create a project in your Rstudio that links to it. Please additionally make folders R/ and /tests/testthat/ in this new directory. We will put your functions and class definitions in .R files in the R/ folder and your tests in .R files in the tests/testthat/ folder. I provide a small section at the end of the homework on how you should moving from being “approach 2” to “approach 3”.

Approach 3 (package start):

Similar to the Approach 2, create a new github public repository please call it percolate and create a project in your Rstudio that links to it. Using usethis::create_package("percolate") create a package in this directory. Make sure in your console you call this function when you are in the folder that contains the folder precolate.

To navigate in the console use `setwd()` and `getwd()` (which sets the directory you're in and returns which directory you're currently in)

You will be using usethis to set up your package and devtools to check your tests, document your functions and more. Please also see closing remarks at the bottom of the file.

Generating and plotting boards

In the first section, we will be creating our new class board as well as helper function and a plot function for our object. We will write generate_board_mat(), and create a class object that can either take in a matrix or generate the board with certain parameters. In this section we will also create the function is_valid() and the method plot.board(). To no surprise, we can represent these boards as square, numeric matrices with dimension n by n. These matrices will only have values 0 (for black “blocked” squares), 1 (for white “open and dry” squares), and 2 (for blue “open and flooded”) squares.

Approach 2: you’ll see the names of files to create / update. Just run the code in these files into your console to get interactions.

Percolating the board

We will now write the percolate.board() method that takes as input start_board (a board) and outputs a list with two entries: result_board, the resulting matrix after “water has been poured”, and result, a boolean on whether or not mat percolates. The function should use the is_valid() function to check that board is a valid matrix first, and then use a separate call to assert_that() to ensure board contains only 0’s and 1’s.

When computing result_board, any open & dry square (i.e, value of 1) in the top row of mat are changed to open & flooded (i.e, changed to a value of 2). When done, result_board should have the same exact pattern of blocked squares (i.e., value of 0) as start_board. In addition, any open & dry square that is adjacent to any open & flooded square becomes open & flooded (via left, right, top and bottom). Once no open & dry square can become open & flooded, your algorithm is done computing result_board. To determine whether or not start_board percolates, check to see if there are any open & flooded square along the bottom row of result_board.

Important: This is not a course about algorithms. You do not need to write an efficient algorithm, but it needs to be correct. Feel free to use any strategy for this algorithm, even if it’s computationally inefficient.

Running experiments

Reading in boards

In this final section, we will write read_boards(), a function that takes in a filepath to a text file and outputs a list of matrices that the text file represents. We describe the specific format of how read_boards() should work. Let file denote the text file that contains our boards. Each board in file is separated by exactly ----, four dashes. There must be ---- before and after each board. If not, read_boards() should error, stating that the file is not properly formatted. This is the only way read_boards() should throw an error. Hence, the length of the returned list is equal to the number of ---- lines in file minus one.

The first non-empty line strictly between the two ---- lines must be a positive integer. This number represents n, the size of the board. The next n lines afterwards then denote the precise pattern of the n by n board, row-wise. Each line represents a row of the board and should have exactly n visible characters, * or .. The * character represents a blocked square, while the . character represents a open square. If the lines between the two ---- lines do not meet these specifications, then return an NA (for an incorrectly specified board) instead of an n by n matrix for this particular board.

Other than storing information pertinent to boards, file should not contain any other visible characters, but file might have extra spaces or extra line breaks.

We provide a small example of what to expect. The file at https://raw.githubusercontent.com/benjaminleroy/36-350-summer-data/master/Week5/percolation_write_example.txt provides 3 boards, the first two of which are correctly specified and the last of which is not. The raw text of this file looks like this:

```
----
4
* . . *
. . * *
. * . .
. . . .
----
5
. . . . .
* . . . *
. . . . *
. * . . *
* * * * .
----
4
. . . .
* . . *
. . a *
. * . .
----
```

The output of `read_boards("https://raw.githubusercontent.com/benjaminleroy/36-350-summer-data/master/Week5/percolation_write_example.txt")` should then be the following:


```
## [[1]]
##      [,1] [,2] [,3] [,4]
## [1,]    0    1    1    0
## [2,]    1    1    0    0
## [3,]    1    0    1    1
## [4,]    1    1    1    1
## attr(,"class")
## [1] "board"  "matrix"
## attr(,"p")
## [1] 0.3125
## attr(,"n")
## [1] 4
## 
## [[2]]
##      [,1] [,2] [,3] [,4] [,5]
## [1,]    1    1    1    1    1
## [2,]    0    1    1    1    0
## [3,]    1    1    1    1    0
## [4,]    1    0    1    1    0
## [5,]    0    0    0    0    1
## attr(,"class")
## [1] "board"  "matrix"
## attr(,"p")
## [1] 0.36
## attr(,"n")
## [1] 5
## 
## [[3]]
## [1] NA
```

**Approaches 2/3:** put this function in the `utils.R` folder (and tests in the correct location as well) and load in your functions before doing problem **4d**. 

Approach 1: Making a package and using version control

Hi there. Congratulations on completing coding of this assignment! We now need to convert the code in this file into a package. First, please save this file as “hw_5-transfer.Rmd” so if you accidently delete things / things aren’t work you can come back to previous work.

Now, we first need to create a github directory (See notes in Wednesday lecture for a refresher). Create a new github public repository please call it percolate and create a project in your Rstudio that links to it.

Following Friday’s lecture, we want to make a package in this project. Using usethis::create_package("percolate") create a package in this directory. Make sure in your console you call this function when you are in the folder that contains the folder precolate.

To navigate in the console use setwd() and getwd() (which sets the directory you’re in and returns which directory you’re currently in)

To set up the package dependencies we’ll be needing today run the following:

usethis::use_testthat()
usethis::use_package("assertthat")
usethis::use_package("ggplot2")

Add all the new files you just created and commit them with a good commit message, e.g. “first commit - initalizing package”.

Now, we’ll be transfering tests and functions from this document to your package directory. Use the usethis::use_r command we learned in Friday’s lecture to create new R function files and use the usethis::use_test command to create new test files (note that usethis::use_test("banana") will create a test-banana.R file).

utils.R and test-utils.R

Run

usethis::use_r("utils")

and store function code you wrote in 1a, 1c. In your console (with the directory as your package directory), run devtools::document(), then run devtools::load_all() look at ?generate_board_mat to see that the documentation is done correctly. Put all examples I request you run into the #' @example section of your documenation.

Run

usethis::use_test("utils")

and store tests of the functions in utils.R (found in 1b, 1c). Run devtools::test(). If this fails, examine where it fails and correct. After tests are running, add all these new files and commit the files you updated.

*To make your package work correctly, at the botton of your documentation for is_valid put

#' @import assertthat

and rerun devtools::document() and devtools::load_all()

board.R and test-board.R

Create a new R file named board.R (same way you created utils.R) and add the function/ class structure defined in 1c. Add associated test to a test files (named test-board.R).

Create documentation your function with devtools::document(), load your package with devtools::load_all(), make sure your tests still run pass with devtools::test() (update if they do not).

Add updated/ new files and commit them.

plot.board and visualize.R Put your plot.board function into the visualize.R file (again you can use usethis::use_r("visualize") to create/ reopen this file). Commit your new code after you’ve documented your package and checked tests (just in case).

** percolate.board and percolate.R** Put percolate.board inot a new file percolate.R, and associated tests in an associated R file. Make sure tests work and functions are documented. Add updated/new files and commit them.

read_board

Put all functions and test associated with problem 4 into your utils.R and test-utils.R files.

Add updated files and commit them (after documenting and testing your functions).

Congrats! Now your code is a package with version control!

doing problem 3

Go to problem 3’s start and follow the directions for Approach 3 (but instead do devtools::install_github("user_name/percolate") in your console and then do library(percolate) at the beginning of this file - see piazza post). Remove code (feel free to also remove text that I wrote as well), above problem 3 (except for problem 1f). Make sure your homework file still knits.

Finally, jump down to the final section of this document labeled Approach 3 (two sections below).

Approach 2

Hi there. Congratulations on completing coding of this assignment while using version control! We now need to convert the code in your directory into a package. Before we go any futher, please make sure you commit all files that you’ve changed and want a snapshot of (it will be impossible to correct errors that occur when transfering to a package if you do not.)

Following Friday’s lecture, we want to make a package in this project. Using usethis::create_package("percolate") create a package in this directory. Make sure in your console you call this function when you are in the folder that contains the folder precolate.

To navigate in the console use `setwd()` and `getwd()` (which sets the directory you're in and returns which directory you're currently in)

You’ll probably notice that the function create_package notices a lot of structure you already have - make sure you only overwrite things that don’t effect the functionality of your code (for example - you should feel free to overwrite the .rproj file, but not any files in R and tests/testthis)

To set up the package dependencies we’ll be needing today run the following:

usethis::use_testthat()
usethis::use_package("assertthat")
usethis::use_package("ggplot2")

Now, run devtools::document() to document all your functions. Check that they are well documented by doing devtools::load_all and then doing things like ?board (you can also look at the create folder man/ and see that all the functions you expect to be documented are).

Now, run devtools::test() make sure all your tests run. Else go back and correct/ update them.

Congrats! Now your code is a package!

doing problem 3

Go to problem 3’s start and follow the directions for Approach 3 (but instead do devtools::install_github("user_name/percolate") in your console and then do library(percolate) at the beginning of this file - see piazza post). Remove code (feel free to also remove text that I wrote as well), above problem 3 (except for problem 1f). Make sure your homework file still knits.

Finally, jump down to the final section of this document labeled Approach 3 (the next section).

Approach 3 / Everyone

Now that you’ve done all the coding, committed all the files you need for the function, etc. We need to do some clean up and push for package to github.

First, open the “DESCRIPTION” file in the main percolate folder. Update this with useful information

Now do the following: - usethis::use_package_doc(): this adds a small documentation file if people want to question your package name

Challenge: Although you’ve used #' @import ggplot2 to have your package put a line in NAMESPACE that says import(ggplot2), it better form to identify the namespace a function come from by doing package_name::function_name. Remove the #' import ggplot2 lines from your documentation, and the import(ggplot2) type lines from the NAMESPACE file. Now run devtools::check()). You’ll see (at minimium) that the we need to actually have tell which namespace functions come from (specifically ggplot2, assert_this and test_this). Do so by doing things like ggplot2::ggplot(ggplot2::aes(...)) + ggplot2::geom_tile(...). Additionally if you use a pipe anywhere run the usethis::use_pipe() command. You may also need to add additional packages to your dependences and more (Feel free to chat with me after the Homework is turned in if you’d like help with this).

What should I submit:

(You may wish to save this file under a different name before making this update).

Please remove all text and code except: 1f, 3a, 3c and 4d (including the devtools::load_all(path = ...) or library(percolate) if you’ve installed from github at the beginning for the Rmd file).

To finish of the assignment, go to this google form and provide your name and github repository link (in the requested format).