Week 5 Assignments

Variant 1: Restaurant Order System

Problem Statement: You are building a simplified system to manage food orders at a restaurant. Orders are represented by integer ticket numbers and are processed in the order they are received (a queue).

You must implement the following four functions:

add_new_orders(orders, new_orders):
- Parameters:
  - orders: The current list of order ticket numbers.
  - new_orders: A list of new ticket numbers to be added.
- Behavior: This function should add each order from new_orders to the end of the orders list.
- Returns: Nothing. It modifies the orders list in-place.
process_orders(orders, num_to_process):
- Parameters:
  - orders: The current list of order ticket numbers.
  - num_to_process: The number of orders to process from the front of the queue.
- Behavior: This function should remove the first num_to_process orders from the orders list.
  - If num_to_process is greater than the number of orders in the list, it should process all remaining orders.
- Returns: A new list containing the ticket numbers of the orders that were processed.
cancel_order(orders, order_id):
- Parameters:
  - orders: The current list of order ticket numbers.
  - order_id: The specific ticket number to cancel and remove.
- Behavior: This function should search for order_id in the orders list and remove its first occurrence.
- Returns:
  - True if the order was found and successfully removed.
  - False if the order_id was not found in the list.
manage_orders(initial_orders, new_orders_to_add, orders_to_process, order_to_cancel):
- Parameters:
  - initial_orders: The starting list of orders.
  - new_orders_to_add: A list of new orders to add.
  - orders_to_process: An integer specifying how many orders to process.
  - order_to_cancel: An integer for the order ID to cancel.
- Behavior: This function orchestrates the entire workflow. It should:
  1. Create a copy of initial_orders to work with, ensuring the original list is not modified.
  2. Call add_new_orders to add the new orders.
  3. Call cancel_order to attempt to cancel the specified order.
  4. Call process_orders to process orders from the front of the queue.
- Returns: The function must return two lists: the final list of orders still in the queue, and the list of orders that were processed. Your return statement should look like this:
```
return final_orders_list, processed_orders_list
```

Testing Inputs:

# Test Case 1
initial = [101, 102, 103, 104]
new = [105, 106]
process_count = 3
cancel_id = 103

# When you call your function, you can receive the two returned lists like this:
final_state, processed = manage_orders(initial, new, process_count, cancel_id)

Expected Output:

Test Case 1 Results:
final_state: [105, 106]
processed: [101, 102, 104]

Original initial list (should be unchanged): [101, 102, 103, 104]

Variant 2: IT Help Desk Ticket System

Problem Statement: You are building a simplified system to manage IT support tickets. Tickets are represented by 4-digit integer IDs and are resolved in the order they are received (a queue).

You must implement the following four functions:

log_new_tickets(tickets, new_tickets):
- Parameters:
  - tickets: The current list of ticket IDs.
  - new_tickets: A list of new ticket IDs to be added.
- Behavior: This function should add each ticket from new_tickets to the end of the tickets list.
- Returns: Nothing. It modifies the tickets list in-place.
resolve_tickets(tickets, num_to_resolve):
- Parameters:
  - tickets: The current list of ticket IDs.
  - num_to_resolve: The number of tickets to resolve from the front of the queue.
- Behavior: This function should remove the first num_to_resolve tickets from the tickets list.
  - If num_to_resolve is greater than the number of tickets in the list, it should resolve all remaining tickets.
- Returns: A new list containing the IDs of the tickets that were resolved.
close_ticket(tickets, ticket_id):
- Parameters:
  - tickets: The current list of ticket IDs.
  - ticket_id: The specific ticket ID to close and remove.
- Behavior: This function should search for ticket_id in the tickets list and remove its first occurrence.
- Returns:
  - True if the ticket was found and successfully removed.
  - False if the ticket_id was not found in the list.
manage_tickets(initial_tickets, new_tickets_to_log, tickets_to_resolve, ticket_to_close):
- Parameters:
  - initial_tickets: The starting list of tickets.
  - new_tickets_to_log: A list of new tickets to add.
  - tickets_to_resolve: An integer specifying how many tickets to resolve.
  - ticket_to_close: An integer for the ticket ID to close.
- Behavior: This function orchestrates the entire workflow. It should:
  1. Create a copy of initial_tickets to work with, ensuring the original list is not modified.
  2. Call log_new_tickets to add the new tickets.
  3. Call close_ticket to attempt to close the specified ticket.
  4. Call resolve_tickets to resolve tickets from the front of the queue.
- Returns: The function must return two lists: the final list of tickets still open, and the list of tickets that were resolved. Your return statement should look like this:
```
return final_tickets_list, resolved_tickets_list
```

Testing Inputs:

# Test Case 1
initial = [4501, 4502, 4503, 4504]
new = [4505, 4506]
resolve_count = 2
close_id = 4502

# When you call your function, you can receive the two returned lists like this:
final_state, resolved = manage_tickets(initial, new, resolve_count, close_id)

Expected Output:

Test Case 1 Results:
final_state: [4504, 4505, 4506]
resolved: [4501, 4503]

Original list (should be unchanged): [4501, 4502, 4503, 4504]

Variant 3: Warehouse Shipment Management

Problem Statement: You are building a simplified system to manage warehouse shipments. Shipments are represented by string IDs (e.g., “BOX-001”) and are dispatched in the order they are received (a queue).

You must implement the following four functions:

receive_new_shipments(shipments, new_shipments):
- Parameters:
  - shipments: The current list of shipment IDs.
  - new_shipments: A list of new shipment IDs to be added.
- Behavior: This function should add each shipment from new_shipments to the end of the shipments list.
- Returns: Nothing. It modifies the shipments list in-place.
dispatch_shipments(shipments, num_to_dispatch):
- Parameters:
  - shipments: The current list of shipment IDs.
  - num_to_dispatch: The number of shipments to dispatch from the front of the queue.
- Behavior: This function should remove the first num_to_dispatch shipments from the shipments list.
  - If num_to_dispatch is greater than the number of shipments in the list, it should dispatch all remaining shipments.
- Returns: A new list containing the IDs of the shipments that were dispatched.
recall_shipment(shipments, shipment_id):
- Parameters:
  - shipments: The current list of shipment IDs.
  - shipment_id: The specific shipment ID to recall and remove.
- Behavior: This function should search for shipment_id in the shipments list and remove its first occurrence.
- Returns:
  - True if the shipment was found and successfully removed.
  - False if the shipment_id was not found in the list.
manage_shipments(initial_shipments, new_shipments_to_receive, shipments_to_dispatch, shipment_to_recall):
- Parameters:
  - initial_shipments: The starting list of shipments.
  - new_shipments_to_receive: A list of new shipments to add.
  - shipments_to_dispatch: An integer specifying how many shipments to dispatch.
  - shipment_to_recall: A string for the shipment ID to recall.
- Behavior: This function orchestrates the entire workflow. It should:
  1. Create a copy of initial_shipments to work with, ensuring the original list is not modified.
  2. Call receive_new_shipments to add the new shipments.
  3. Call recall_shipment to attempt to recall the specified shipment.
  4. Call dispatch_shipments to dispatch shipments from the front of the queue.
- Returns: The function must return two lists: the final list of shipments remaining, and the list of shipments that were dispatched. Your return statement should look like this:
```
return final_shipments_list, dispatched_shipments_list
```

Testing Inputs:

# Test Case 1
initial = ["BOX-A1", "BOX-B2", "BOX-C3", "BOX-D4"]
new = ["BOX-E5", "BOX-F6"]
dispatch_count = 2
recall_id = "BOX-D4"

# When you call your function, you can receive the two returned lists like this:
final_state, dispatched = manage_shipments(initial, new, dispatch_count, recall_id)

Expected Output:

Test Case 1 Results:
final_state: ['BOX-C3', 'BOX-E5', 'BOX-F6']
dispatched: ['BOX-A1', 'BOX-B2']

Original list unchanged: ['BOX-A1', 'BOX-B2', 'BOX-C3', 'BOX-D4']

Variant 4: Gaming Leaderboard

Problem Statement: You are building a system to manage a high-score leaderboard for an arcade game. The system tracks player names and their corresponding scores using two separate but parallel lists.

You must implement the following four functions:

add_player(players, scores, new_player, new_score):
- Parameters:
  - players: The current list of player names.
  - scores: The parallel list of player scores.
  - new_player: The name of the new player to add.
  - new_score: The score of the new player.
- Behavior: Adds the new player and score to the end of their respective lists.
- Returns: Nothing. It modifies the lists in-place.
remove_player(players, scores, player_to_remove):
- Parameters:
  - players: The list of player names.
  - scores: The parallel list of scores.
  - player_to_remove: The name of the player to remove.
- Behavior: Finds the index of player_to_remove and removes the player from the players list and their score from the scores list.
- Returns:
  - True if the player was found and removed.
  - False if the player was not found.
get_top_players(players, scores, count):
- Parameters:
  - players: A list of player names.
  - scores: The parallel list of scores.
  - count: The number of top players to retrieve.
- Behavior: This function should find the count players with the highest scores. You may not use built-in functions like sort() or max(). You must implement the logic to find the highest score repeatedly.
  - The function should not modify the original players and scores lists.
- Returns: A new list containing the names of the top players, ordered from highest score to lowest.
manage_leaderboard(initial_players, initial_scores, new_player_data, player_to_remove, top_count):
- Parameters:
  - initial_players, initial_scores: The starting parallel lists.
  - new_player_data: A list containing the new player’s name and score (e.g., ["KAY", 9500]).
  - player_to_remove: The name of the player to remove.
  - top_count: The number of top players to find.
- Behavior: Orchestrates the workflow:
  1. Create copies of the initial lists to work with.
  2. Call add_player with the new player data.
  3. Call remove_player.
  4. Call get_top_players to find the leaders from the updated lists.
- Returns: Two lists: the final state of the players list and the list of top player names.
```
return final_players_list, top_player_names
```

Testing Inputs:

# Test Case 1
players = ["ACE", "BAM", "CID", "DAZ", "EGG"]
scores = [8800, 7500, 9200, 8100, 7900]
new_player = ["FIN", 9300]
remove_name = "BAM"
count = 3

# When you call your function:
final_players, top_list = manage_leaderboard(players, scores, new_player, remove_name, count)

Expected Output:

# For Test Case 1, the variables should hold:
Final Players: ['ACE', 'CID', 'DAZ', 'EGG', 'FIN']
Top List: ['FIN', 'CID', 'ACE']

Variant 5: Product Inventory Management

Problem Statement: You are building a system for a luxury goods store to track its most valuable products. The system uses two parallel lists: one for product names and one for their prices.

You must implement the following four functions:

add_product(products, prices, new_product, new_price):
- Parameters:
  - products: The current list of product names.
  - prices: The parallel list of product prices.
  - new_product: The name of the new product to add.
  - new_price: The price of the new product.
- Behavior: Adds the new product and price to the end of their respective lists.
- Returns: Nothing. It modifies the lists in-place.
remove_product(products, prices, product_to_remove):
- Parameters:
  - products: The list of product names.
  - prices: The parallel list of prices.
  - product_to_remove: The name of the product to remove.
- Behavior: Finds the index of product_to_remove and removes the product from the products list and its price from the prices list.
- Returns:
  - True if the product was found and removed.
  - False if the product was not found.
get_most_valuable(products, prices, count):
- Parameters:
  - products: A list of product names.
  - prices: The parallel list of prices.
  - count: The number of most valuable products to retrieve.
- Behavior: This function should find the count products with the highest prices. You may not use built-in functions like sort() or max(). You must implement the logic to find the highest price repeatedly.
  - The function should not modify the original products and prices lists.
- Returns: A new list containing the names of the most valuable products, ordered from most to least expensive.
manage_inventory(initial_products, initial_prices, new_product_data, product_to_remove, top_count):
- Parameters:
  - initial_products, initial_prices: The starting parallel lists.
  - new_product_data: A list containing the new product’s name and price (e.g., ["Vase", 450.00]).
  - product_to_remove: The name of the product to remove.
  - top_count: The number of most valuable products to find.
- Behavior: Orchestrates the workflow:
  1. Create copies of the initial lists to work with.
  2. Call add_product with the new product data.
  3. Call remove_product.
  4. Call get_most_valuable to find the top items from the updated lists.
- Returns: Two lists: the final state of the products list and the list of most valuable product names.
```
return final_products_list, top_product_names
```

Testing Inputs:

# Test Case 1
products = ["Watch", "Ring", "Bag", "Scarf", "Pen"]
prices = [5500.00, 7200.00, 3100.00, 800.00, 1200.00]
new_product = ["Statue", 6800.00]
remove_name = "Scarf"
count = 3

# When you call your function:
final_products, top_list = manage_inventory(products, prices, new_product, remove_name, count)

Expected Output:

# For Test Case 1, the variables should hold:
Final products: ['Watch', 'Ring', 'Bag', 'Pen', 'Statue']
Top list: ['Ring', 'Statue', 'Watch']

Variant 6: Race Results Tracking

Problem Statement: You are building a system to track lap times for a car race. The system uses two parallel lists: one for racer names and one for their single fastest lap time (in seconds).

You must implement the following four functions:

add_racer(racers, lap_times, new_racer, new_time):
- Parameters:
  - racers: The current list of racer names.
  - lap_times: The parallel list of lap times.
  - new_racer: The name of the new racer to add.
  - new_time: The lap time of the new racer.
- Behavior: Adds the new racer and lap time to the end of their respective lists.
- Returns: Nothing. It modifies the lists in-place.
disqualify_racer(racers, lap_times, racer_to_disqualify):
- Parameters:
  - racers: The list of racer names.
  - lap_times: The parallel list of lap times.
  - racer_to_disqualify: The name of the racer to disqualify.
- Behavior: Finds the index of racer_to_disqualify and removes the racer from the racers list and their time from the lap_times list.
- Returns:
  - True if the racer was found and removed.
  - False if the racer was not found.
get_fastest_laps(racers, lap_times, count):
- Parameters:
  - racers: A list of racer names.
  - lap_times: The parallel list of lap times.
  - count: The number of fastest racers to retrieve.
- Behavior: This function should find the count racers with the fastest (lowest) lap times. You may not use built-in functions like sort() or min(). You must implement the logic to find the lowest time repeatedly.
  - The function should not modify the original racers and lap_times lists.
- Returns: A new list containing the names of the fastest racers, ordered from fastest to slowest lap.
manage_race_results(initial_racers, initial_times, new_racer_data, racer_to_disqualify, top_count):
- Parameters:
  - initial_racers, initial_times: The starting parallel lists.
  - new_racer_data: A list containing the new racer’s name and time (e.g., ["Viper", 91.55]).
  - racer_to_disqualify: The name of the racer to disqualify.
  - top_count: The number of fastest racers to find.
- Behavior: Orchestrates the workflow:
  1. Create copies of the initial lists to work with.
  2. Call add_racer with the new racer data.
  3. Call disqualify_racer.
  4. Call get_fastest_laps to find the top racers from the updated lists.
- Returns: Two lists: the final state of the racers list and the list of fastest racer names.
```
return final_racers_list, fastest_racer_names
```

Testing Inputs:

# Test Case 1
racers = ["Axel", "Blaze", "Cruz", "Dash", "Echo"]
times = [95.42, 94.88, 96.10, 95.90, 94.99]
new_racer = ["Fang", 94.50]
disqualify_name = "Dash"
count = 3

# When you call your function:
final_racers, fastest_list = manage_race_results(racers, times, new_racer, disqualify_name, count)

Expected Output:

# For Test Case 1, the variables should hold:
Final racers: ['Axel', 'Blaze', 'Cruz', 'Echo', 'Fang']
Fastest list: ['Fang', 'Blaze', 'Echo']

Variant 7: Library Book Management

Problem Statement: You are creating a system to help a library manage its book collection. The system tracks book titles and their total checkout counts for the year in two parallel lists.

You must implement the following four functions:

update_checkout_count(books, counts, book_title, new_count):
- Parameters:
  - books: The current list of book titles.
  - counts: The parallel list of checkout counts.
  - book_title: The title of the book to update.
  - new_count: The new checkout count for that book.
- Behavior: Finds the book_title in the books list and updates the corresponding value in the counts list to new_count.
- Returns: True if the book was found and updated, False otherwise.
remove_unpopular_books(books, counts, min_checkouts):
- Parameters:
  - books: The list of book titles.
  - counts: The parallel list of checkout counts.
  - min_checkouts: The minimum number of checkouts a book must have to remain in the collection.
- Behavior: Removes all books (and their corresponding counts) from the lists in-place if their checkout count is less than min_checkouts.
- Returns: Nothing. It modifies the lists directly.
categorize_by_popularity(books, counts, popular_threshold):
- Parameters:
  - books: A list of book titles.
  - counts: The parallel list of checkout counts.
  - popular_threshold: A book with this many checkouts or more is considered “Popular”.
- Behavior: Creates two new lists: one for “Popular” books and one for “Regular” books. It should not modify the original lists.
- Returns: The two new lists: popular_books, regular_books.
analyze_library_stock(initial_books, initial_counts, book_to_update, unpopular_threshold, popular_threshold):
- Parameters:
  - initial_books, initial_counts: The starting parallel lists.
  - book_to_update: A list containing the book title and its new count (e.g., ["Moby Dick", 20]).
  - unpopular_threshold: The checkout count below which books are removed.
  - popular_threshold: The checkout count above which books are categorized as popular.
- Behavior: Orchestrates the analysis:
  1. Create copies of the initial lists to work with.
  2. Call update_checkout_count with the data from book_to_update.
  3. Call remove_unpopular_books to clean the lists.
  4. Call categorize_by_popularity on the cleaned lists.
- Returns: The two lists of categorized book titles generated by the final step.
```
return popular_books_list, regular_books_list
```

Testing Inputs:

# Test Case 1
books = ["Moby Dick", "1984", "Dune", "War and Peace"]
counts = [15, 130, 95, 25]
update_info = ["Moby Dick", 20]
unpopular_min = 22
popular_min = 100

# When you call your function:
popular, regular = analyze_library_stock(books, counts, update_info, unpopular_min, popular_min)

Expected Output:

# For Test Case 1, the variables should hold:
popular: ['1984']
regular: ['Dune', 'War and Peace']

Variant 8: Employee Performance Review

Problem Statement: You are building a tool for HR to analyze annual employee performance. The system tracks employee names and their performance scores (0-100) in two parallel lists.

You must implement the following four functions:

update_employee_score(employees, scores, employee_name, new_score):
- Parameters:
  - employees: The current list of employee names.
  - scores: The parallel list of performance scores.
  - employee_name: The name of the employee to update.
  - new_score: The new performance score for that employee.
- Behavior: Finds the employee_name in the employees list and updates the corresponding value in the scores list to new_score.
- Returns: True if the employee was found and updated, False otherwise.
remove_underperforming(employees, scores, min_score):
- Parameters:
  - employees: The list of employee names.
  - scores: The parallel list of performance scores.
  - min_score: The minimum score an employee must have to be retained.
- Behavior: Removes all employees (and their corresponding scores) from the lists in-place if their score is less than min_score.
- Returns: Nothing. It modifies the lists directly.
group_by_performance(employees, scores, high_performer_threshold):
- Parameters:
  - employees: A list of employee names.
  - scores: The parallel list of performance scores.
  - high_performer_threshold: An employee with this score or more is a “High Performer”.
- Behavior: Creates two new lists: one for “High Performer” employees and one for “Core Contributor” employees. It should not modify the original lists.
- Returns: The two new lists: high_performers, core_contributors.
run_performance_review(initial_employees, initial_scores, employee_to_update, min_performance_score, high_performer_score):
- Parameters:
  - initial_employees, initial_scores: The starting parallel lists.
  - employee_to_update: A list containing the employee’s name and new score (e.g., ["Alice", 72]).
  - min_performance_score: The score below which employees are removed.
  - high_performer_score: The score above which employees are categorized as high performers.
- Behavior: Orchestrates the analysis:
  1. Create copies of the initial lists to work with.
  2. Call update_employee_score with the data from employee_to_update.
  3. Call remove_underperforming to clean the lists.
  4. Call group_by_performance on the cleaned lists.
- Returns: The two lists of categorized employee names generated by the final step.
```
return high_performers_list, core_contributors_list
```

Testing Inputs:

# Test Case 1
employees = ["Alice", "Bob", "Charlie", "David"]
scores = [70, 95, 88, 74]
update_info = ["Alice", 72]
min_required_score = 75
high_perf_score = 90

# When you call your function:
high_performers, core_contributors = run_performance_review(employees, scores, update_info, min_required_score, high_perf_score)

Expected Output:

Test Case 1 Results:
high_performers: ['Bob']
core_contributors: ['Charlie']

Original lists unchanged:
employees: ['Alice', 'Bob', 'Charlie', 'David']
scores: [70, 95, 88, 74]

Variant 9: Server Health Monitoring

Problem Statement: You are writing a script for a data center to monitor server health. The script tracks server IDs and their average CPU utilization percentage (0-100) in two parallel lists.

You must implement the following four functions:

update_cpu_usage(servers, usages, server_id, new_usage):
- Parameters:
  - servers: The current list of server IDs.
  - usages: The parallel list of CPU usages.
  - server_id: The ID of the server to update.
  - new_usage: The new CPU usage for that server.
- Behavior: Finds the server_id in the servers list and updates the corresponding value in the usages list to new_usage.
- Returns: True if the server was found and updated, False otherwise.
decommission_idle_servers(servers, usages, idle_threshold):
- Parameters:
  - servers: The list of server IDs.
  - usages: The parallel list of CPU usages.
  - idle_threshold: A server with CPU usage less than this value is considered idle and should be decommissioned.
- Behavior: Removes all idle servers (and their corresponding usages) from the lists in-place.
- Returns: Nothing. It modifies the lists directly.
flag_server_load(servers, usages, high_load_threshold):
- Parameters:
  - servers: A list of server IDs.
  - usages: The parallel list of CPU usages.
  - high_load_threshold: A server with this usage or more is flagged as “High Load”.
- Behavior: Creates two new lists: one for “High Load” servers and one for “Normal Load” servers. It should not modify the original lists.
- Returns: The two new lists: high_load_servers, normal_load_servers.
analyze_server_health(initial_servers, initial_usages, server_to_update, decommission_threshold, high_load_threshold):
- Parameters:
  - initial_servers, initial_usages: The starting parallel lists.
  - server_to_update: A list containing the server’s ID and its new usage (e.g., ["db-01", 14.0]).
  - decommission_threshold: The usage below which servers are removed.
  - high_load_threshold: The usage above which servers are categorized as high load.
- Behavior: Orchestrates the analysis:
  1. Create copies of the initial lists to work with.
  2. Call update_cpu_usage with the data from server_to_update.
  3. Call decommission_idle_servers to clean the lists.
  4. Call flag_server_load on the cleaned lists.
- Returns: The two lists of categorized server IDs generated by the final step.
```
return high_load_list, normal_load_list
```

Testing Inputs:

# Test Case 1
servers = ["db-01", "app-01", "web-01", "cache-01"]
usages = [12.5, 88.0, 75.5, 15.0]
update_info = ["db-01", 14.0]
idle_max_usage = 18.0
high_load_min_usage = 80.0

# When you call your function:
high_load, normal_load = analyze_server_health(servers, usages, update_info, idle_max_usage, high_load_min_usage)

Expected Output:

# For Test Case 1, the variables should hold:
high_load: ['app-01']
normal_load: ['web-01']

Variant 10: Video Game Inventory Management

Problem Statement: You are developing an inventory system for a role-playing game. The player’s inventory is represented by two parallel lists: item_names and item_quantities. You need to write a system that processes a list of gameplay events (transactions) that modify this inventory.

You must implement the following two functions:

find_item_index(item_names, item_name):
- Parameters:
  - item_names: A list of strings representing the names of items in the inventory.
  - item_name: The name of the item to find.
- Behavior: This helper function should search for item_name in the item_names list.
- Returns: The index of the item if found, or -1 if the item is not in the list.
process_inventory_events(initial_items, initial_quantities, events):
- Parameters:
  - initial_items: The starting list of item names.
  - initial_quantities: The starting parallel list of item quantities.
  - events: A list of “event” sub-lists. Each sub-list contains a command and its arguments.
- Behavior: This function orchestrates the entire process. It should:
  1. Create copies of the initial lists to work with.
  2. Iterate through the events list. For each event, it should parse the command and update the inventory lists accordingly.
  3. It must use your find_item_index helper function to locate items.
Event Commands to Handle:
- ["PICKUP", "Item Name", Quantity]:
  - If the item exists, increase its quantity.
  - If the item does not exist, add it to the inventory with the given quantity.
- ["USE", "Item Name", Quantity]:
  - If the item exists and has sufficient quantity, decrease its quantity by the amount used.
  - If the quantity of an item drops to 0 or below after being used, the item should be completely removed from both lists.
  - If the item doesn’t exist or there isn’t enough quantity, this event does nothing.
- ["DROP", "Item Name"]:
  - If the item exists, it is completely removed from the inventory, regardless of quantity.
  - If the item does not exist, this event does nothing.
- Returns: The function must return two lists: the final state of the item_names list and the final state of the item_quantities list.
```
return final_item_names_list, final_item_quantities_list
```

Testing Inputs:

# Test Case 1
items = ["Sword", "Health Potion", "Gold Coin"]
quantities = [1, 5, 100]
game_events = [
    ["PICKUP", "Gold Coin", 50],
    ["USE", "Health Potion", 2],
    ["DROP", "Sword"],
    ["PICKUP", "Magic Scroll", 1],
    ["USE", "Health Potion", 3]  # This will cause the item to be removed
]

# When you call your function:
final_items, final_quantities = process_inventory_events(items, quantities, game_events)

Expected Output:

Final Inventory:
final_items: ['Gold Coin', 'Magic Scroll']
final_quantities: [150, 1]

Variant 11: Bank Account Ledger

Problem Statement: You are building a system to process daily transactions for a small bank. The bank’s accounts are stored in two parallel lists: account_ids and account_balances. You need to process a ledger of transactions that affect these accounts.

You must implement the following two functions:

find_account_index(account_ids, account_id):
- Parameters:
  - account_ids: A list of strings representing the unique IDs of bank accounts.
  - account_id: The ID of the account to find.
- Behavior: This helper function should search for account_id in the account_ids list.
- Returns: The index of the account if found, or -1 if the account is not in the list.
process_ledger(initial_accounts, initial_balances, transactions):
- Parameters:
  - initial_accounts: The starting list of account IDs.
  - initial_balances: The starting parallel list of account balances.
  - transactions: A list of “transaction” sub-lists. Each sub-list contains a command and its arguments.
- Behavior: This function orchestrates the entire process. It should:
  1. Create copies of the initial lists to work with.
  2. Iterate through the transactions list. For each transaction, it should parse the command and update the account lists accordingly.
  3. It must use your find_account_index helper function to locate accounts.
Transaction Commands to Handle:
- ["OPEN", "Account ID", Initial Deposit]:
  - If the account ID does not already exist, add it to the system with the given initial deposit.
  - If the account ID already exists, this transaction does nothing.
- ["DEPOSIT", "Account ID", Amount]:
  - If the account exists, increase its balance by the amount.
  - If the account does not exist, this transaction does nothing.
- ["WITHDRAW", "Account ID", Amount]:
  - If the account exists and has a sufficient balance, decrease its balance by the amount.
  - If the account doesn’t exist or has an insufficient balance, this transaction does nothing.
- Returns: The function must return two lists: the final state of the account_ids list and the final state of the account_balances list.
```
return final_account_ids_list, final_account_balances_list
```

Testing Inputs:

# Test Case 1
accounts = ["ACC-001", "ACC-002", "ACC-003"]
balances = [500.00, 1200.00, 250.00]
daily_transactions = [
    ["DEPOSIT", "ACC-001", 150.00],
    ["WITHDRAW", "ACC-002", 250.00],
    ["WITHDRAW", "ACC-003", 300.00], # This should fail (insufficient funds)
    ["OPEN", "ACC-004", 1000.00],
    ["DEPOSIT", "ACC-002", 50.00]
]

# When you call your function:
final_accounts, final_balances = process_ledger(accounts, balances, daily_transactions)

Expected Output:

# For Test Case 1, the variables should hold:
Final Accounts: ['ACC-001', 'ACC-002', 'ACC-003', 'ACC-004']
Final Balances: [650.0, 1000.0, 250.0, 1000.0]

Variant 12: Event Hall Seating Management

Problem Statement: You are tasked with creating a system for a concert hall to manage seat availability in different sections. The hall’s layout is stored in two parallel lists: section_names and seats_available. You need to process a list of booking operations.

You must implement the following two functions:

find_section_index(section_names, section_name):
- Parameters:
  - section_names: A list of strings representing the names of seating sections.
  - section_name: The name of the section to find.
- Behavior: This helper function should search for section_name in the section_names list.
- Returns: The index of the section if found, or -1 if the section is not in the list.
process_bookings(initial_sections, initial_seats, operations):
- Parameters:
  - initial_sections: The starting list of section names.
  - initial_seats: The starting parallel list of available seats in each section.
  - operations: A list of “operation” sub-lists. Each sub-list contains a command and its arguments.
- Behavior: This function orchestrates the entire process. It should:
  1. Create copies of the initial lists to work with.
  2. Iterate through the operations list. For each operation, it should parse the command and update the seating lists accordingly.
  3. It must use your find_section_index helper function to locate sections.
Operation Commands to Handle:
- ["ADD_SECTION", "Section Name", Capacity]:
  - If the section does not already exist, add it to the hall with the given seating capacity.
  - If the section already exists, this operation does nothing.
- ["BOOK", "Section Name", Num Seats]:
  - If the section exists and has enough available seats, decrease the number of available seats.
  - If the section doesn’t exist or has too few seats, this operation does nothing.
- ["CANCEL", "Section Name", Num Seats]:
  - If the section exists, increase its available seats by the number of canceled seats. (Assume you can’t cancel more seats than the section’s total capacity, but you don’t need to track capacity, just add them back).
  - If the section does not exist, this operation does nothing.
- Returns: The function must return two lists: the final state of the section_names list and the final state of the seats_available list.
```
return final_section_names_list, final_seats_available_list
```

Testing Inputs:

# Test Case 1
sections = ["Orchestra", "Mezzanine", "Balcony"]
seats = [50, 75, 100]
booking_operations = [
    ["BOOK", "Mezzanine", 10],
    ["BOOK", "Orchestra", 60], # This should fail (not enough seats)
    ["CANCEL", "Balcony", 5],
    ["ADD_SECTION", "Box Seats", 12],
    ["BOOK", "Orchestra", 20]
]

# When you call your function:
final_sections, final_seats = process_bookings(sections, seats, booking_operations)

Expected Output:

Initial state:
  Sections: ['Orchestra', 'Mezzanine', 'Balcony']
  Seats: [50, 75, 100]

Processing operations:
1. BOOK Mezzanine 10: 75 -> 65
2. BOOK Orchestra 60: Failed (only 50 available)
3. CANCEL Balcony 5: 100 -> 105
4. ADD_SECTION Box Seats 12: Added new section
5. BOOK Orchestra 20: 50 -> 30

Final state:
  Sections: ['Orchestra', 'Mezzanine', 'Balcony', 'Box Seats']
  Seats: [30, 65, 105, 12]