프로 그래 밍 프로그램 설명, R 과정 프로그램 지도

Project tasksMany academic departments have walk-in academic advising during busy periods in the semester (e.g., Drop/Addweek). The Department of Statistics currently has one academic advisor on staff. We are interested in usingsimulation 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 possibleto 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 thenmake small modifications until we have accomplished our goal. We will adopt this philosophy and begin with aworking 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 customersvisiting a teller at a bank)? Specifically, remark on (A) what is represented by the index, i , that islooped 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 summarystatistics of totaltime from each run of your Bank Teller simulation. (Note: don't be surprised if youhave 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 simulationwith the longest MAXIMUM wait time of any customer.Task 1.5 Show the summary statistics corresponding to the 6 iterations of your Bank Teller simulationwith the longest average wait time.Task 1.6 Use the following arrival and duration data to verify the outcome shown as evidence thatyour teller simulation code works properly:arrival duration Outcome: show that your approach results in totaltime of 3, 3, 5, 8, 15, and 12 respectivelyNote: the previous bank teller simulation both simulates customers AND the teller who servesthem. Just extract the "teller" portion of the code to verify that it is working properly, and thenshow totaltime directly.for (i in 1:length(customers)) {numcust if (numcust != 0) {arrival[position:(position + numcust - 1)] position }}Part 2. Academic advisor simulationNow that you are confident that your Bank Teller simulation is working properly, we will modify it to simulate thecontext of academic advising as described previously.Task 2.1 Describe how you would interpret each of the following elements from our bank tellersimulation 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 thefollowing 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 thatyour academic advisor simulation code works properly:arrival duration Outcome: show that your approach results in totaltime of 20, 11, 19, 45, and 51 respectivelyTask 2.4 Use mosaic::do() to repeat the simulation at least 20 times, and then store the summarystatistics of totaltime from each run of your walk-in advising simulation. (Note: don't be surprised ifyou 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 advisingsimulation 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 advisingshifts. Add a "rug plot" to show the actual simulated outcomes observed in the margin of your plot. Besure 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 wantto study the impact of adding a second walk-in advisor during busy periods like Drop/Add week at the beginning ofthe 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 havesuccessfully implemented a second academic advisor helping students in parallel on a first-come, firstservedbasis:arrival duration Outcome: show that your approach results in totaltime of 20, 11, 15, 31, and 16, respectivelyTask 3.2 Breifly describe a bullet list of the changes that you made in order to incorporate a secondacademic advisor.Task 3.3 Use mosaic::do() to repeat the simulation at least 20 times, and then store the summarystatistics of totaltime from each run of your walk-in advising simulation with TWO academicadvisors 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 advisingsimulation 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 advisingshifts with TWO academic advisors working in parallel. Add a "rug plot" to show the actual simulatedoutcomes observed in the margin of your plot. Be sure to use good plotting practices.Part 4. ObservationsTask 4.1 Use the following information to update the number of simulations in your study above. Noneed 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 commandscan be used like a timer in order to predict how long it will take you to run your simulations. For example, you coulddo a "small" one that takes a few seconds like we did earlier and then repeat a couple times for slightly largervolume of simulations (e.g., 40 & 80). Now you have three data points which will (hopefully) verify that the timerequired increasing more or less linearly. Now you can extrapolate how many simulations you want to run in someamount of time... 15 minutes? an hour?? more??? If you intend to cite specific simulation results when you shareobservations 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 aboutwhether or not there would be much benefit if she hires a second academic advisor during Drop/Addweeks.
calculate computing time for 20 sims
ptm testing Sys.time() - ptm
calculate computing time for 40 sims
ptm testing Sys.time() - ptm
calculate computing time for 80 sims
ptm testing Sys.time() - ptm
WX：codehelp