I've finally solved this after one wrong answer and a few hours. It is more fiddly than it first looks. I managed rank 62/2333
Some gotchas/hints:
1) Algorithm is graph BFS and with a non-recursive depth track twist. I personally did this with an adjacency list but a matrix should work equally well.
2) Like several other people, if I increased my MAX_EDGES constant from 32 to 64, this was the
only difference between AC and WA. I think there's an inaccuracy in the specification here.
3) Part of the reason why I spent so much time is that I also got my algorithm generate graphviz output (coloured nodes - visited blue, unvisited red). I found this useful for diagnosing edge cases and was quite quick to add. I'll leave this as exercise to the reader to implement in their own code
Here is example graphviz output (matching 1.png below):
Code: Select all
graph "start = 1 TTL = 5" { 100 [fillcolor=blue,style=filled]; 2 [fillcolor=blue,style=filled]; 3 [fillcolor=blue,style=filled]; 4 [fillcolor=blue,style=filled]; 5 [fillcolor=blue,style=filled]; 6 [fillcolor=blue,style=filled]; 7 [fillcolor=blue,style=filled]; 8 [fillcolor=blue,style=filled]; 9 [fillcolor=blue,style=filled]; 1000 [fillcolor=blue,style=filled]; 100100 [fillcolor=blue,style=filled]; 1002 [fillcolor=red,style=filled]; 1003 [fillcolor=red,style=filled]; 1004 [fillcolor=blue,style=filled]; 1005 [fillcolor=blue,style=filled]; 1006 [fillcolor=blue,style=filled]; 1007 [fillcolor=blue,style=filled]; 1008 [fillcolor=blue,style=filled]; 1009 [fillcolor=blue,style=filled]; 20 [fillcolor=blue,style=filled]; 2100 [fillcolor=blue,style=filled]; 22 [fillcolor=blue,style=filled]; 23 [fillcolor=blue,style=filled]; 100 -- 2; 100 -- 4; 100 -- 7; 2 -- 3; 3 -- 4; 3 -- 9; 5 -- 6; 5 -- 22; 6 -- 7; 7 -- 8; 7 -- 2100; 8 -- 9; 8 -- 1006; 8 -- 100100; 9 -- 1000; 1000 -- 100100; 1000 -- 20; 1002 -- 1003; 1003 -- 1004; 1004 -- 1005; 1005 -- 1006; 1006 -- 1007; 1007 -- 1008; 1008 -- 1009; 1009 -- 20; 20 -- 2100; 2100 -- 22; 22 -- 23;
}
4) As was also pointed out above, the large sample input given on this forum is helpful a bit misleading in one specific edge case. From analysing the mismatches between this and my AC code, I think most of the differences are cases where a query is made from a non-existent node. E.g. if only nodes 10,11 defined then asking for query from node 12. I think behaviour of this type of query is undefined and the judge input (rightly) does not care about these cases.
5) In the judge sample input, I've inferred that there are no nodes with self-referential edges i.e. no edge linking node a to node a. I figured this out from comparing with Mark Greve's (excellent) UVA Toolkit site/reference solutions, which show differences in this case with my AC solution (yet both his and my solution are AC by the judge). Hence, again I think the judge input does not include such cases.
Here is another test case - this does not include any queries from undefined nodes. This has long/short cycles and is non-trivial and avoids cases (4) and (5) noted above.
INPUT
Code: Select all
28
100 2 2 3 3 4 4 100
5 6 6 7 7 8 8 9 9 1000 1000 100100 9 3 100 7
1002 1003 1003 1004 1004 1005 1005 1006 1006 1007 1007 1008 1008 1009 1009 20 20 2100 2100 22 22 23
1006 8 1000 20 22 5 7 2100 8 100100
100 5 7 3 1005 3 1004 5 2100 6 1000 99 0 0
0
OUTPUT
Code: Select all
Case 1: 2 nodes not reachable from node 100 with TTL = 5.
Case 2: 4 nodes not reachable from node 7 with TTL = 3.
Case 3: 12 nodes not reachable from node 1005 with TTL = 3.
Case 4: 6 nodes not reachable from node 1004 with TTL = 5.
Case 5: 1 nodes not reachable from node 2100 with TTL = 6.
Case 6: 0 nodes not reachable from node 1000 with TTL = 99.
Attached also are graphviz (dot) graphs for the first 3 cases in the above input (this is the maximum number of file attachments, unfortunately!).
Hope this is useful to someone.