讲解programming程序、R课程程序辅导
Project tasks
Many academic departments have walk-in academic advising during busy periods in the semester (e.g., Drop/Add
week). The Department of Statistics currently has one academic advisor on staff. We are interested in using
simulation to understand how long students are likely to wait for walk-in advising during these busy periods.
Furthermore, the head of the statistics department would like to understand the potential impact if it were possible
to hire a second advisor to assist during those periods.
Part 1. Bank teller simulation.
In programming, it's often a good idea to start with some working code that accomplishes a similar task, and then
make small modifications until we have accomplished our goal. We will adopt this philosophy and begin with a
working example from the Bank Teller simulation discussed in class.
Task 1.1 Reproduce the Bank Teller simulation here exactly as it is described in your MDSR textbook (p.
232 & 233).
Task 1.2 Clearly explain what this portion of the provided code does (in the context of customers
visiting a teller at a bank)? Specifically, remark on (A) what is represented by the index, i , that is
looped over;
(B) what is included in each element of the customers object;
(C) what does numcust !=
0 mean;
(D) what is included in each element of the arrival object.
Note: include=FALSE
causes R to run the code, but does not show this chunk in the R
Notebook
always clean up R environment
rm(list = ls())
packages
library(mosaic)
library(tidyverse)
inputs & source data
user-defined functions
A. B. C. D.
Task 1.3 Use mosaic::do() to repeat the simulation at least 20 times, and then store the summary
statistics of totaltime from each run of your Bank Teller simulation. (Note: don't be surprised if you
have to wait at least 20-30 seconds, depending on your computer)
Task 1.4 Show the summary statistics corresponding to the 6 iterations of your Bank Teller simulation
with the longest MAXIMUM wait time of any customer.
Task 1.5 Show the summary statistics corresponding to the 6 iterations of your Bank Teller simulation
with the longest average wait time.
Task 1.6 Use the following arrival and duration data to verify the outcome shown as evidence that
your teller simulation code works properly:
arrival <- c(1, 3, 7, 10, 11, 15)
duration <- c(3, 2, 5, 6, 8, 1)
Outcome: show that your approach results in totaltime of 3, 3, 5, 8, 15, and 12 respectively
Note: the previous bank teller simulation both simulates customers AND the teller who serves
them. Just extract the "teller" portion of the code to verify that it is working properly, and then
show totaltime directly.
for (i in 1:length(customers)) {
numcust <- customers[i]
if (numcust != 0) {
arrival[position:(position + numcust - 1)] <- rep(i, numcust)
position <- position + numcust
}
}
Part 2. Academic advisor simulation
Now that you are confident that your Bank Teller simulation is working properly, we will modify it to simulate the
context of academic advising as described previously.
Task 2.1 Describe how you would interpret each of the following elements from our bank teller
simulation in the context of the academic advising simulation:
A. Bank teller:
B. Bank customer:
C. hours :
D. n :
E. m :
Task 2.2 Show how you would modify the teller simulation to simulate an academic advisor under the
following conditions:
6.5 hours of walk-in advising each day during Drop/Add week;
we expect one a new student to arrive every 12 minutes, on average;
we expect each of the walk-in advising appointments to last about 10 minutes on average.
Task 2.3 Use the following arrival and duration data to verify the outcome shown as evidence that
your academic advisor simulation code works properly:
arrival <- c(7, 42, 49, 54, 55)
duration <- c(20, 11, 15, 31, 7)
Outcome: show that your approach results in totaltime of 20, 11, 19, 45, and 51 respectively
Task 2.4 Use mosaic::do() to repeat the simulation at least 20 times, and then store the summary
statistics of totaltime from each run of your walk-in advising simulation. (Note: don't be surprised if
you have to wait at least 20-30 seconds, depending on your computer)
Task 2.5 Show the summary statistics corresponding to the 6 iterations of your walk-in advising
simulation in which the advisor served the MOST STUDENTS in a day (i.e., 6.5 hour period).
Task 2.6 Show a density plot of the third quartile of totaltime among simulated walk-in advising
shifts. Add a "rug plot" to show the actual simulated outcomes observed in the margin of your plot. Be
sure to use good plotting practices.
Part 3. Adding a second advisor.
Now that we understand the simulation and have translated it to the context of walk-in academic advising, we want
to study the impact of adding a second walk-in advisor during busy periods like Drop/Add week at the beginning of
the semester.
Task 3.1 You will need to modify the code from Part 2 in order to introduce a second academic advisor.
Use the following arrival and duration data to verify the outcome shown as evidence that you have
successfully implemented a second academic advisor helping students in parallel on a first-come, firstserved
basis:
arrival <- c(7, 42, 49, 54, 55)
duration <- c(20, 11, 15, 31, 7)
Outcome: show that your approach results in totaltime of 20, 11, 15, 31, and 16, respectively
Task 3.2 Breifly describe a bullet list of the changes that you made in order to incorporate a second
academic advisor.
Task 3.3 Use mosaic::do() to repeat the simulation at least 20 times, and then store the summary
statistics of totaltime from each run of your walk-in advising simulation with TWO academic
advisors helping students in parallel on a first-come, first-served basis.
Task 3.4 Show the summary statistics corresponding to the 6 iterations of your walk-in advising
simulation in which the TWO advisors served the MOST STUDENTS in a day (i.e., 6.5 hour period).
Task 3.5 Show a density plot of the third quartile of totaltime among simulated walk-in advising
shifts with TWO academic advisors working in parallel. Add a "rug plot" to show the actual simulated
outcomes observed in the margin of your plot. Be sure to use good plotting practices.
Part 4. Observations
Task 4.1 Use the following information to update the number of simulations in your study above. No
need to show results here, the updated simulation quantity above is sufficient.
Before sharing observations... it would be helpful to have a LOT more than 20 simulations. A few simple commands
can be used like a timer in order to predict how long it will take you to run your simulations. For example, you could
do a "small" one that takes a few seconds like we did earlier and then repeat a couple times for slightly larger
volume of simulations (e.g., 40 & 80). Now you have three data points which will (hopefully) verify that the time
required increasing more or less linearly. Now you can extrapolate how many simulations you want to run in some
amount of time... 15 minutes? an hour?? more??? If you intend to cite specific simulation results when you share
observations below, make sure you use set.seed appropriately in your project.
Task 4.2 Compare your simulation results to make a recommendation to the Department Head about
whether or not there would be much benefit if she hires a second academic advisor during Drop/Add
weeks.
calculate computing time for 20 sims
ptm <- Sys.time()
testing <- two_advisor_results <- mosaic::do(20) * two_advisor_sim()
Sys.time() - ptm
calculate computing time for 40 sims
ptm <- Sys.time()
testing <- two_advisor_results <- mosaic::do(40) * two_advisor_sim()
Sys.time() - ptm
calculate computing time for 80 sims
ptm <- Sys.time()
testing <- two_advisor_results <- mosaic::do(80) * two_advisor_sim()
Sys.time() - ptm
【讲解programming程序、R课程程序辅导】WX:codehelp
推荐阅读
- 基于微信小程序带后端ssm接口小区物业管理平台设计
- 事件处理程序
- 编写字典程序
- 演讲手势
- Java程序员阅读源码的小技巧,原来大牛都是这样读的,赶紧看看!
- 小程序有哪些低成本获客手段——案例解析
- 程序员|【高级Java架构师系统学习】毕业一年萌新的Java大厂面经,最新整理
- 微信小程序基础知识
- VueX(Vuex|VueX(Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式)
- 使用Promise对微信小程序wx.request请求方法进行封装