Challenge Overview
Problem Statement  
Prizes
BackgroundGranfalloon Delivery Logistics (GDL) is responsible for scheduling ongoing deliveries to customers. Continuously improving safety is always an important objective for GDL. Because safety has been the top priority at GDL, accidents during delivery are extremely rare. In the effort to continuously improve safety even where there are no accidents, GDL uses on board computers (OBC) to monitor properties like speed, acceleration, deceleration, and stability during deliveries and to identify events which might indicate increased risk. For example, a deceleration and/or stability event can indicate that pilots we required to take evasive action, perhaps to avoid a collision or other hazard. GDL is searching for ways to use its information about past trips and events to help schedule ever safer trips by choosing routes that avoid these kinds of events. GDL has compiled records of more than 50,000 trips including variables related to route, known route risks, date, time, driver, weather, and traffic. These trips have been correlated with information about events. Under 6% of the trips have safety events associated with them. Under 1% of trips have more than 1 safety event associated with it. Multievent information for trips is included. In addition to finding a way to detect trips likely to include safety events, GDL would like to collect relevant information on reasons for selecting various techniques as well as any insights the solution might reveal about the structure and correlations in the data. To complete eligible for the prizes, authors of winning solutions will be required to document their solution, evaluate strengths and weaknesses of their solution, and describe what the solution might reveal about the data. Data DictionaryColumn name Description Id A unique identifier given to each trip. An individual trip can include loading, traveling to one or more customer sites to deliver, and even returning to reload (see complexity). A trip has dates & times, at least a primary pilot, underlying route record, cargo information. source Identifier for the location at which the trip began. dist The total distance covered by this trip. cycles Cycle N means that this trip was the N���th trip scheduled in a batch of trips assigned to a pilot and optionally a copilot. complexity A proxy measure for the overall complexity of the trip. Higher is more complicated. Roughly, this is the number of ���trip segments��� where a segment might be related to actual route, or it might relate to loading, unloading, refueling or other procedures in the trip. cargo Identifier for the type of cargo being carried on this trip. stops Number of distinct delivery stops required for the trip. start_day An integer number representing the day on which this trip started. start_month An integer number representing the month on which this trip started. start_day_of_month The day of the month on which this trip started. start_day_of_week An integer 1 thru 7 representing the day of the week on which this trip started. start_time Time of day at which trip began. HH:MM, 24 hr clock. days Length of this trip in days to two decimal places. pilot Identifier for the primary pilot of the vehicle. pilot2 Identifier for the copilot of the vehicle, if there is one. 0 indicates no copilot. pilot_exp Number indicating the level of experience for the primary pilot. pilot_visits_prev Number of time the primary pilot has recently made deliveries using this route; serves as a measure of pilot familiarity with the route. pilot_hours_prev The number of hours that the primary pilot has been working on trips in a time period immediately prior to this trip. Might be an indicator of a ���cold��� pilot low or zero hours or of pilot fatigue for high hours. pilot_duty_hrs_prev The number of hours the primary pilot has been actively piloting in a time period prior to this trip. Trips involve activities beyond piloting, such as loading, unloading, resting, etc. pilot_dist_prev The distance the primary pilot has accumulated in the past 3 days prior to the start of this trip. route_risk_1 A proxy measurement for the relative danger of route. Higher number is higher risk. The number is based on the vicinity of the route, not the exact route. route_risk_2 A second proxy measurement for the relative danger of route. Higher number is higher risk. The number is based on the vicinity of the route, not the exact route. weather An integer number indicating a worst case weather condition encountered on a trip. So, if weather conditions were icy during a small part of the trip and clear during the rest, then weather for this trip is classified as ���icy��� The integer value represents only a type of weather and is not a ranking of severity. visibility Scoring from 1 to 50 of the average overall visibility throughout the trip to one decimal place. traf0 Number of travel segments from the trip with unknown congestion. traf1 Number of very congested trip segments. traf2 Number of congested trip segments. traf3 Number of lightly congested trip segments. traf4 Number of uncongested trip segments. Each training record includes four event counters for each trip. Solutions are not required to rank by type, only whether speed_events + decel_events + accel_events + stability_events > 0 Column name Description accel_cnt The number of rapid acceleration events reported by the OBC for this trip. decel_cnt The number of rapid deceleration events reported by the OBC for this trip. speed_cnt The number of high speed events reported by the Onboard Computer (OBC) for this trip. stability_cnt The number of stability warning events reported by the OBC for this trip. evt_cnt Total number of events for this trip. Sum of speed_cnt + decel_cnt + accel_cnt + stability_cnt A Simplified Example SolutionWhen given (1) training data that includes information about trips and events and (2) a set of input data that does not include alarm frequencies, then the contestant algorithms should respond with a ranked list of trips from (2) that it determines are most likely to contain alarm events. An oversimplified example with the silly assumption that ���RED traffic��� is the only factor correlating to events: Input (1)  Training DataTraining Data Pilot Traffic Events 100 10 RED 1 101 10 GREEN 0 102 11 RED 1 103 12 GREEN 0 104 12 RED 1 Input (2)  To Be RankedTesting Data Pilot Traffic 500 10 RED 501 10 GREEN 502 11 GREEN 503 11 GREEN 504 13 BLUE 505 13 RED Output  Sample Response from a SolutionRoute Return Data (Rank) 500 1 501 3 502 4 503 5 504 6 505 2 Keying off the correlation with ���RED��� traffic, this solution to the simplified problem has ranked the two red trips before the other trips. The actual order of the RED trips 500 and 505 is arbitrary unless the solution has reason to suspect that one is more likely to have events than the other, in which case the solution should order them accordingly. Since Pilots 10 and 13 both had ���RED��� events, a more complicated solution might place both trips 501 and 504 immediately after the RED trips, speculating that pilot might also be a factor in the likelihood of events. Specification for SolutionImplementationYour task is to implement a method to rank trips from most likely to contain events to least likely to contain events. The signature of this method is specified in the Definition section below. Both string[] trainingData and string[] testingData will contain comma delimited strings. Each string describes the information from a particular trip. The order of values and the kind of data in each string is specified in the ���Data Dictionary.��� Each string of trainingData will have 34 string values, including the event count for each trip. Each string in the element of testingData will have only 29 string values and will not not contain the number of events. Your solution method should return a list of ranks assigned to each trip. the list should be the same length as testingData. You response should rank order all trips such that those with the highest safety concern are assigned with a lower rank in the list. All values in the returned array must be unique and the lowest rank should be 1. return[i] is the assigned rank for testingData[i] Scoring by Relative Ranking:
Let N be the number of trips with at least one event, and let M <= N be the number for trips with more than one event occurred during the trip. Each rank is assigned with a score and a bonus. scores[i] := MAX( (2N  i) / 2N, 0 ) where scores[i] is the score of rank i  1 bonuses[i] := MAX( (2M  i) / 2M * 0.3, 0 ) where bonuses[i] is the bonus for rank i  1 score := 0 for i := 0, 1, ..., sizeOf(yourResult)1 { truePositive := testingData[i] is true positive highSafetyConcern := testingData[i] is elevated safety concern score := score + truePositive * scores[yourResult[i]1] + highSafetyConcern * bonuses[yourResult[i]1] } score := 1000000 * score / max_possible_score The overall score on a set of test cases is the arithmetic average of scores on single test cases from the set. The match standings displays overall scores on provisional tests for all competitors who have made at least 1 full test submission. The winners are competitors with the highest overall scores on system tests. Notes on Data Set Generation
 
Definition  
 
Notes  
  The time limit is 5 minutes. The memory limit is 2048 megabytes.  
  The compilation time limit is 30 seconds. You can find information about compilers that we use and compilation options here.  
  There are 5 example test cases and 100 full submission (provisional) test cases.  
  Example data is here.  
  Scoring snippet is here.  
Examples  
0)  
 
1)  
 
2)  
 
3)  
 
4)  

This problem statement is the exclusive and proprietary property of TopCoder, Inc. Any unauthorized use or reproduction of this information without the prior written consent of TopCoder, Inc. is strictly prohibited. (c)2020, TopCoder, Inc. All rights reserved.