Round 3 2013


  Submissions
Cheaters
7pt
Not attempted
250/365 users correct (68%)
10pt
Not attempted
201/223 users correct (90%)
Rural Planning
9pt
Not attempted
97/137 users correct (71%)
13pt
Not attempted
9/28 users correct (32%)
Are We Lost Yet?
12pt
Not attempted
85/127 users correct (67%)
18pt
Not attempted
23/53 users correct (43%)
Observation Wheel
8pt
Not attempted
242/255 users correct (95%)
23pt
Not attempted
3/6 users correct (50%)
  Top Scores
Gennady.Korotkevich64
vepifanov64
SnapDragon64
theycallhimtom64
mystic64
mikhailOK64
winger64
dzhulgakov64
qwerty78778864
PavelKunyavskiy64
Practice Mode

Contest Analysis

Overview  |  Problem A  |  Problem B  |  Problem C  |  Problem D

Introduction

The problem asks you to determine which part of a path E1, E2, ..., Ek can be a prefix of some shortest path from 1 to 2. This would be easy if not for the fact we don't know the exact edge costs - we only know ranges into which they fall.

Small dataset

Let's concentrate on any fixed prefix E1, E2, ..., Ep of the proposed path, and try to make it a prefix of some shortest path. If we decide on a shortest path candidate (that includes our prefix), it's obivously advantageous to assume the edges on our path are as short as possible, and the other edges are as long as possible.

Notice that a consequence of this is that we can just restrict ourselves to looking at graphs in which each of the edges is either as long or as short as possible. Thus, since in the small dataset the number of edges is only 20, we can simply check all possibilities - make some of the edges short, the rest long, find the shortest path in the resulting graph (preferring the proposed path by, for instance, decreasing the cost of the edges on this path by a small epsilon), and then out of all the possibilities pick the one that takes the most steps along the proposed path.

Large dataset

This is obviously not going to fly for the large dataset. Again, we fix a prefix E1, E2, ..., Ep of the proposed path and try to make it a prefix of the shortest path. Assume Ep ends in Tokyo. Thus, we will try to get from Tokyo to London as fast as possible, while still not allowing for a shorter path from Mountain View to London that doesn't begin with our prefix. If we want to optimize for speed, we can do a binary search for the longest prefix that can be a start of some shortest path; if we optimize for simplicity, we can just iterate over all prefixes.

Imagine two robots that try to reach London as fast as possible. One starts from Tokyo, and has a handicap of the cost to travel from the Mountain View to Tokyo along the proposed path (we call this the "good" robot). When this robot goes across an edge, it will always take the minimal cost - this robot represents the shortest path we hope to construct. The other robot starts from Mountain View, and tries to reach London via some other path. We call this the "bad" robot and will try to force it to take as long as possible. The question is whether we can make the good robot be at least as fast as the bad robot (the bad robot can obviously be equally fast simply by following the good robot).

We already set the costs for the edges E1 to Ep to the low values. Since our aim is to make the good robot move fast and the bad robot move slow, a naive approach is to simply have the good robot pay the low cost for all other edges, and the bad robot pay the high cost. However, we will still encounter a problem in this model. If two robots go across a same edge, they are actually taking different costs, which is not possible in a fixed configuration.

Notice, however, that the two robots are walking the same graph. Thus, if they reach a same node at a different time, the one that arrived earlier will always beat the other one if the shortest path goes through that node, because it can always follow the other one’s route. This means the later robot does not have any purpose in visiting this node at all. Since ties are resolved in favor of the good robot, we can simply decrease the good robot's handicap by 0.5 to avoid any ties.

Thus, we can solve the problem with a single run of Dijkstra's algorithm. We begin with two starting points - one in Mountain View at time 0, and the other in Tokyo with time equal to the cost of travel along the proposed path to Tokyo minus 0.5. When processing a node, we calculate the costs of outgoing edges as follows:

  • If the edge is one of E1, ..., Ep, we take the low cost.
  • If the current node is processed because the good robot reached it (which we know because the cost of the current node is not an integer, it ends with 0.5), the cost is the low cost.
  • Otherwise, we are processing the node because the bad robot reached it, and the cost is the high cost.
As Dijkstra's algorithm visits a node only once to process outgoing edges, we will never have a robot visit a node that the other robot reached earlier.

You cannot ask questions at this time. Please email us at codejam@google.com.
You have 0 submissions.