ComputerScienceExpert

(11)

$18/per page/

About ComputerScienceExpert

Levels Tought:
Elementary,Middle School,High School,College,University,PHD

Expertise:
Applied Sciences,Calculus See all
Applied Sciences,Calculus,Chemistry,Computer Science,Environmental science,Information Systems,Science Hide all
Teaching Since: Apr 2017
Last Sign in: 103 Weeks Ago, 4 Days Ago
Questions Answered: 4870
Tutorials Posted: 4863

Education

  • MBA IT, Mater in Science and Technology
    Devry
    Jul-1996 - Jul-2000

Experience

  • Professor
    Devry University
    Mar-2010 - Oct-2016

Category > Programming Posted 06 May 2017 My Price 8.00

Develop a simulation of an elevator

Elevator project

Develop a simulation of an elevator that travels between floors 1 and N where N is an input. Time is sequenced in discrete steps starting at 1; at each time step, the elevator may ascend one floor, descend one floor, or remain at its current floor, as determined by its strategy. The first line of the input file indicates the number N of floors. This is followed by one line per person using the elevator: her id, call time (when she calls for the elevator), origin floor (from which she boards the elevator), and destination floor (from which she debarks the elevator). For example:

5     

100  2   1   4     

101  3   4   5     

102  3   3   2     

103  5   5   1     

104  5   1   4

Here, individual 100 boards at time 2 from floor 1 with a destination of floor 4. Assume sensible inputs (e.g., times are positive integers, floors are integers in the range 1 through N, origin and destination floors are distinct for each passenger).

Whenever the elevator stops at a floor from which people have called it (i.e., their origin floor but not before their call time), they all board the elevator. And whenever the elevator stops at any passengers’ destination floor, they all get off the elevator. (Everyone gets on and gets off so as to minimize their travel time.) The simulation stops when every individual has been brought to her destination floor (subject of course to their call time and origin floor constraints).

The simulation proceeds in integer time steps, starting at time 1. In each time step t, where the elevator is currently on floor f, the elevator is notified of:

    1. every person who calls at time t and her floor of origin (where she’s calling from);
    2. every person who gets on at floor f and her destination floor; and
    3. every person who gets off at floor f (which would be her destination floor).

A strategy determines the floor the elevator begins on at time 1, and a policy for moving to the next floor (up one floor, down one floor, or remaining at the current floor) from one time step to the next. Here is a simple strategy:

Strategy 1: Start at floor 1. In each time step, successively go up one floor until reaching the top floor N, then successively go down one floor until reaching the bottom floor 1, and continue this ‘up to the top floor and then down to the bottom floor’ policy.

Note that this strategy doesn’t use notifications 1−3 above; the elevator just moves up and down, receiving and discharging passengers, until the last scheduled passenger arrives at her destination floor and the simulation ends. Here we run the simulation using the input file data1.in (given above) and Strategy 1:

>> sim = Simulation.new
=> #<Simulation:0x27d3fc8>
>> sim.run('data1.in', :strategy1)

Time 1: Floor 1

Time 2: Floor 2

      100 calls from floor 1

Time 3: Floor 3

101 calls from floor 4

102 calls from floor 3

102 boards from floor 3

Time 4: Floor 4

101 calls from floor 4

Time 5: Floor 5

      103 calls from floor 5

      104 calls from floor 1

      103 boards from floor 5

      101 debarks onto floor 5

Time 6: Floor 4

Time 7: Floor 3

Time 8: Floor 2

102 debarks onto floor 2

Time 9: Floor 1

100 boards from floor 1

104 boards from floor 1

103 debarks onto floor 1

Time 10: Floor 2

Time 11: Floor 3

Time 12: Floor 4

100 debarks onto floor 4

104 debarks onto floor 4

=> nil

We measure the efficiency of a strategy with respect to the passengers’ average wait time. Let’s say that someone’s wait time is the number of time steps from her call time until she reaches her destination floor. So wait time is the time waiting for the elevator to arrive at the origin floor plus the time traveling in the elevator to the destination floor. For example, the wait times for customers 100 through 104 are 10, 2, 5, 4, and 7, respectively. Then we define the efficiency of a strategy (with respect to input) to be the average wait time over all scheduled passengers. Our simulation reports this value for the simulation shown above:

>> puts sim.average_wait_time 5.6

Here is what you need to submit:

    1. A scenario diagram for the case where a customer calls the elevator, the elevator arrives, she boards, the elevator moves (over time) to her destination floor, and she debarks. You may devise other diagrams but this one is essential. Note that we will spend some time in class working on design for this project.
    2. Implement Strategy 1 as part of your project. In addition, devise and implement a second strategy that is generally more efficient than Strategy 1. Where sim is a Simulation object, we run a simulation like this:

sim.run(filename_string, strategy_symbol)
The symbol :strategy2 should identify your (more efficient) strategy.

    1. Write a method

sim.multirun(nbr_runs, filename_prefix, strategy)

that runs your program nbr_runs many times on the input files named by filename_prefix with suffixes 000.in, 001.in, ..., and returns the average efficiency. For example:

sim.multirun(15, 'myelev', :strategy2)

runs your Strategy 2 on the files myelev000.in, ..., myelev014.in and returns the average of the 15 efficiency values. I will give you a set of input files to test your program on, and you should report the average efficiency you obtain on these files for both strategies. You can also use these input files to compare your strategy to other strategies, with respect to efficiency. I’ll also give you a Ruby program to generate your own test files.
4. Submit your Ruby code for this project, in addition to your scenario diagram, in a zip archive by the due date.

Answers

(11)
Status NEW Posted 06 May 2017 06:05 AM My Price 8.00

-----------

Not Rated(0)