Elevator System (SCAN Scheduling)

Elevator System (SCAN Scheduling)

A single-car elevator running the SCAN (elevator!) algorithm under a deterministic tick clock — scheduling policy as testable design.

Requirements — the scheduling policy (SCAN)

1. Idle car, new tick: if requests are pending, set direction toward the earliest-arrived pending request; otherwise stay.
2. Each tick the car moves exactly one floor in its direction. Arriving at a pending floor serves (clears) it.
3. Keep going while any pending floor lies ahead in the current direction — the car serves floors it passes even if they were requested later (that's the SCAN sweep).
4. When nothing is pending ahead but requests remain behind, reverse direction. When nothing is pending at all, become idle.
5. A request for the car's current floor is served immediately and never enters the pending set.

API to implement

Implement the class Elevator. The I/O driver is already written in the starter code — it parses the command script below and calls your methods. You only implement the class.

| Command | Returns | Behavior | |---|---|---| | request <floor> | — | Someone requests floor. If the car is already there, the request is served instantly (no-op). Duplicate pending requests collapse into one. | | step | int | Advance one time tick per the scheduling policy below; return the car's floor after the tick. With no pending requests the car stays put. | | pos | int | Current floor (no time passes). | | pending_count | int | Number of distinct floors still waiting to be served. |

Input format

The first line contains Q, the number of operations. The second line contains the constructor argument: floors — number of floors, 0 … floors-1; the car starts at floor 0, idle. Each of the next Q lines is one command as listed above. String arguments contain no spaces.

Output format

For each command with a non-void return, print its result on its own line, in order. The driver does this for you — your methods just return values.

This is a design problem: the hidden tests exercise edge cases and interaction sequences, not performance tricks. Model the state cleanly and the tests will pass.

10
10
request 3
request 1
step
step
step
pending_count
step
step
pos
pending_count

1
2
3
0
3
3
3
0

12
8
request 2
step
request 5
request 1
step
step
step
step
step
step
step
pos

1
2
3
4
5
5
5
5
5