| task_name,problem_type,instruction,instance,solution,obj,instance_variant,solution_variant,context_index,input_format,input_index_base | |
| MDS,MDS,"Recently the city asked for an efficient kiosk layout: pick the minimum number of intersections to host kiosks so that every intersection either has one or connects to one. Efficiency is measured by the kiosk count — just add up how many kiosks are placed and prefer the plan with the lowest total — and each kiosk is tied to one intersection only, so it can’t be counted more than once. The rule is strict: every intersection must be covered by being a kiosk location or adjacent to one, and the exact instance details are shown below. | |
| The instance has 20 intersections and 20 streets: | |
| Street connecting intersection 12 and intersection 6. | |
| Street connecting intersection 12 and intersection 13. | |
| Street connecting intersection 13 and intersection 7. | |
| Street connecting intersection 13 and intersection 14. | |
| Street connecting intersection 14 and intersection 15. | |
| Street connecting intersection 15 and intersection 16. | |
| Street connecting intersection 16 and intersection 17. | |
| Street connecting intersection 17 and intersection 18. | |
| Street connecting intersection 18 and intersection 19. | |
| Street connecting intersection 19 and intersection 20. | |
| Street connecting intersection 1 and intersection 2. | |
| Street connecting intersection 2 and intersection 3. | |
| Street connecting intersection 3 and intersection 4. | |
| Street connecting intersection 4 and intersection 5. | |
| Street connecting intersection 5 and intersection 6. | |
| Street connecting intersection 6 and intersection 7. | |
| Street connecting intersection 7 and intersection 8. | |
| Street connecting intersection 8 and intersection 9. | |
| Street connecting intersection 9 and intersection 10. | |
| Street connecting intersection 10 and intersection 11. | |
| Pick a kiosk placement that uses the fewest kiosks while covering every intersection. | |
| Also, when you send back the actual plan, a tiny JSON snippet like this keeps things simple and easy to check: | |
| { | |
| ""solution"": [""intersection_id"", ""intersection_id"", ...] | |
| } | |
| Here ""solution"" is just the list of intersections (the spots where you'd place kiosks). Think of it like filling in a form: list the intersection IDs you choose in that array. This JSON is only a sketch of the shape I expect — not the real answer itself. | |
| Please use the identifiers exactly as they appear in the instance input — do not rename them or introduce new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 20, 'edges': [{'u': 12, 'v': 6}, {'u': 12, 'v': 13}, {'u': 13, 'v': 7}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}], 'source_file': 'great-britain_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0000.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0000.png', 'edge_connectivity': 1}","[2, 5, 7, 10, 13, 16, 19]",7.0,"{'num_nodes': 20, 'num_edges': 20, 'edges': [{'u': 12, 'v': 6}, {'u': 12, 'v': 13}, {'u': 13, 'v': 7}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}]}","[2, 5, 7, 10, 13, 16, 19]",1,nl,1 | |
| MDS,MDS,"A friend is planning detector placement and the idea is to choose a small set of rooms to equip so every room either has an alarm or shares a wall with a room that does. The task is to pick which rooms get detectors; better plans use fewer detectors, so compare plans by counting how many detectors each requires and choose the smallest count. It’s essential that no room be left uncovered, and putting more than one detector in a single room instead of covering an uncovered neighbor is wasteful. The specific layout and numbers are shown below. | |
| There are 25 rooms and 26 shared walls: | |
| Room T shares a wall with room K. | |
| Room T shares a wall with room X. | |
| Room T shares a wall with room Y. | |
| Room U shares a wall with room S. | |
| Room F shares a wall with room G. | |
| Room F shares a wall with room J. | |
| Room F shares a wall with room O. | |
| Room G shares a wall with room H. | |
| Room I shares a wall with room J. | |
| Room I shares a wall with room K. | |
| Room I shares a wall with room R. | |
| Room I shares a wall with room S. | |
| Room K shares a wall with room L. | |
| Room K shares a wall with room O. | |
| Room L shares a wall with room M. | |
| Room M shares a wall with room N. | |
| Room N shares a wall with room B. | |
| Room P shares a wall with room E. | |
| Room P shares a wall with room Q. | |
| Room Q shares a wall with room R. | |
| Room A shares a wall with room B. | |
| Room A shares a wall with room E. | |
| Room B shares a wall with room C. | |
| Room C shares a wall with room D. | |
| Room V shares a wall with room W. | |
| Room W shares a wall with room X. | |
| Choose detectors so every room is covered with as few detectors as possible; avoid putting extra detectors in a room instead of covering an uncovered neighbor. | |
| Also, when you reply, please put the chosen rooms into a tiny JSON snippet so it's easy to read and check. Something like this: | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| This just shows the shape I want: ""solution"" is a list of the rooms where you'll place detectors — one entry per room. The values shown are placeholders, not the actual answer. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 26, 'edges': [{'u': 20, 'v': 11}, {'u': 20, 'v': 24}, {'u': 20, 'v': 25}, {'u': 21, 'v': 19}, {'u': 6, 'v': 7}, {'u': 6, 'v': 10}, {'u': 6, 'v': 15}, {'u': 7, 'v': 8}, {'u': 9, 'v': 10}, {'u': 9, 'v': 11}, {'u': 9, 'v': 18}, {'u': 9, 'v': 19}, {'u': 11, 'v': 12}, {'u': 11, 'v': 15}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 2}, {'u': 16, 'v': 5}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 1, 'v': 2}, {'u': 1, 'v': 5}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}], 'source_file': 'netherlands_osm.mtx', 'density': 0.08666666666666667, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0001.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0001.png', 'edge_connectivity': 1}","[3, 5, 6, 7, 13, 17, 19, 20, 23]",9.0,"{'num_nodes': 25, 'num_edges': 26, 'edges': [{'u': 'T', 'v': 'K'}, {'u': 'T', 'v': 'X'}, {'u': 'T', 'v': 'Y'}, {'u': 'U', 'v': 'S'}, {'u': 'F', 'v': 'G'}, {'u': 'F', 'v': 'J'}, {'u': 'F', 'v': 'O'}, {'u': 'G', 'v': 'H'}, {'u': 'I', 'v': 'J'}, {'u': 'I', 'v': 'K'}, {'u': 'I', 'v': 'R'}, {'u': 'I', 'v': 'S'}, {'u': 'K', 'v': 'L'}, {'u': 'K', 'v': 'O'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'B'}, {'u': 'P', 'v': 'E'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'A', 'v': 'B'}, {'u': 'A', 'v': 'E'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'V', 'v': 'W'}, {'u': 'W', 'v': 'X'}]}","['C', 'E', 'F', 'G', 'M', 'Q', 'S', 'T', 'W']",2,nl,names | |
| MDS,MDS,"There’s a neighborhood fair coming up and the organizer wants to post the smallest number of volunteers at booths so that every booth either has someone or sits beside a booth that does. The decision is which specific booths get people; a good decision is the one that uses the least number of volunteers while still making sure every booth is covered. One can judge a plan by counting assigned volunteers and checking that no booth gets skipped or double-booked. The full booth map and specifics are shown below. | |
| # total_booths=24 | |
| # adjacent_booth_pairs=26 | |
| booth_a,booth_b | |
| A,D | |
| B,C | |
| B,H | |
| B,I | |
| C,D | |
| C,G | |
| D,E | |
| E,F | |
| F,Q | |
| I,J | |
| J,K | |
| J,T | |
| K,L | |
| L,M | |
| M,N | |
| M,X | |
| N,O | |
| N,W | |
| O,P | |
| P,Q | |
| Q,R | |
| R,S | |
| T,U | |
| U,V | |
| V,W | |
| V,X | |
| Just so it's easy to hand back to the organizer or a parsing script, here's the shape I expect the reply to take — nothing fancy, just plain JSON with the list of chosen booths. | |
| { | |
| ""solution"": [""booth_id"", ""booth_id"", ...] | |
| } | |
| Think of ""solution"" as the form field where you list the booths you want to staff. Each entry in that array is one booth identifier from the map. This is just a sketch of the shape I want, not the actual set of booths for the fair. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 26, 'edges': [{'u': 1, 'v': 4}, {'u': 2, 'v': 3}, {'u': 2, 'v': 8}, {'u': 2, 'v': 9}, {'u': 3, 'v': 4}, {'u': 3, 'v': 7}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 17}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 10, 'v': 20}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 13, 'v': 24}, {'u': 14, 'v': 15}, {'u': 14, 'v': 23}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 22, 'v': 24}], 'source_file': 'belgium_osm.mtx', 'density': 0.09420289855072464, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0002.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0002.png', 'edge_connectivity': 1}","[2, 3, 4, 10, 13, 14, 17, 18, 22]",9.0,"{'num_nodes': 24, 'num_edges': 26, 'edges': [{'u': 'A', 'v': 'D'}, {'u': 'B', 'v': 'C'}, {'u': 'B', 'v': 'H'}, {'u': 'B', 'v': 'I'}, {'u': 'C', 'v': 'D'}, {'u': 'C', 'v': 'G'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'Q'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'J', 'v': 'T'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'M', 'v': 'X'}, {'u': 'N', 'v': 'O'}, {'u': 'N', 'v': 'W'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'T', 'v': 'U'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'W'}, {'u': 'V', 'v': 'X'}]}","['B', 'C', 'D', 'J', 'M', 'N', 'Q', 'R', 'V']",3,csv,names | |
| MDS,MDS,"At school there’s a neat challenge: build a tiny team of class representatives so every student is either on that team or sits beside someone who is. What makes one plan better than another is simply that it uses fewer students, so test arrangements and keep the one with the smallest number that still leaves no one uncovered. Every student must be reached and reps should be distinct individuals. The specific instance and seating info are shown below. | |
| There are 23 students in total and 22 adjacent pairs. | |
| | student_u_id | student_v_id | | |
| |---|---| | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 2 | | |
| | 16 | 4 | | |
| | 16 | 17 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 20 | | |
| | 0 | 1 | | |
| | 0 | 22 | | |
| | 1 | 2 | | |
| | 21 | 10 | | |
| | 20 | 10 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| Oh, and when you send back the tiny team, just use this simple JSON layout so it's easy to parse: | |
| { | |
| ""solution"": [""seat_id"", ""seat_id"", ...] | |
| } | |
| Think of ""solution"" as the list of chosen seats (one entry per class rep). The placeholders in the array just show the shape I need — they're not the real answers, just a sketch of what to put. | |
| Please make sure you use the identifiers exactly as they appear in the instance input — no renaming, no made-up labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 3}, {'u': 17, 'v': 5}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 1, 'v': 2}, {'u': 1, 'v': 23}, {'u': 2, 'v': 3}, {'u': 22, 'v': 11}, {'u': 21, 'v': 11}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}], 'source_file': 'belgium_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0003.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0003.png', 'edge_connectivity': 1}","[1, 4, 5, 6, 9, 11, 12, 15, 19]",9.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 2}, {'u': 16, 'v': 4}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 0, 'v': 1}, {'u': 0, 'v': 22}, {'u': 1, 'v': 2}, {'u': 21, 'v': 10}, {'u': 20, 'v': 10}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}]}","[0, 3, 4, 5, 8, 10, 11, 14, 18]",4,markdown_table,0 | |
| MDS,MDS,"In a small library the job is to choose a handful of shelves to display wayfinding panels so every shelf is either displaying a panel itself or sits next to a shelf that does. What counts as a “better” choice is straightforward: the fewer panels used the better, and the count of panels is the simple measure to compare plans. Ensure every shelf is covered by that rule, and don’t waste panels by duplicating them on the same shelf. The specific shelf map appears below. | |
| There are 19 shelves and 18 adjacency pairs on the map below. | |
| Shelf 1 is adjacent to shelf 2; a panel on either shelf covers the other. | |
| Shelf 2 is adjacent to shelf 3; a panel on either shelf covers the other. | |
| Shelf 3 is adjacent to shelf 4; a panel on either shelf covers the other. | |
| Shelf 4 is adjacent to shelf 5; a panel on either shelf covers the other. | |
| Shelf 5 is adjacent to shelf 6; a panel on either shelf covers the other. | |
| Shelf 5 is adjacent to shelf 10; a panel on either shelf covers the other. | |
| Shelf 6 is adjacent to shelf 7; a panel on either shelf covers the other. | |
| Shelf 7 is adjacent to shelf 8; a panel on either shelf covers the other. | |
| Shelf 8 is adjacent to shelf 9; a panel on either shelf covers the other. | |
| Shelf 10 is adjacent to shelf 11; a panel on either shelf covers the other. | |
| Shelf 10 is adjacent to shelf 17; a panel on either shelf covers the other. | |
| Shelf 11 is adjacent to shelf 12; a panel on either shelf covers the other. | |
| Shelf 12 is adjacent to shelf 13; a panel on either shelf covers the other. | |
| Shelf 13 is adjacent to shelf 14; a panel on either shelf covers the other. | |
| Shelf 14 is adjacent to shelf 15; a panel on either shelf covers the other. | |
| Shelf 15 is adjacent to shelf 16; a panel on either shelf covers the other. | |
| Shelf 17 is adjacent to shelf 18; a panel on either shelf covers the other. | |
| Shelf 18 is adjacent to shelf 19; a panel on either shelf covers the other. | |
| Use as few panels as possible to cover all 19 shelves. | |
| When you’re ready, just send back the chosen shelves in a tiny JSON snippet like this: | |
| { | |
| ""solution"": [""shelf_id"", ""shelf_id"", ...] | |
| } | |
| Think of ""solution"" as the list of shelf labels where you’d put panels — one entry per shelf. The JSON above is just the shape I’m expecting, not the actual answer. | |
| Please use the exact identifiers from the instance input — don’t rename them or invent new ones. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 5, 'v': 10}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 10, 'v': 11}, {'u': 10, 'v': 17}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}], 'source_file': 'great-britain_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0004.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0004.png', 'edge_connectivity': 1}","[2, 5, 8, 12, 15, 18]",6.0,"{'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 5, 'v': 10}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 10, 'v': 11}, {'u': 10, 'v': 17}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}]}","[2, 5, 8, 12, 15, 18]",5,nl,1 | |
| MDS,MDS,"Recently the team was tasked with deciding where to place monitoring agents across a set of interconnected servers so every machine ends up observed. The practical rule is to install agents on as few servers as possible — evaluate each option by counting the agent hosts and pick the smallest count — while making sure no server is left without an agent or a direct neighbor with one, and without installing agents in places that don’t add coverage. The detailed server map appears below. | |
| { | |
| ""total_servers"": 20, | |
| ""total_connections"": 20, | |
| ""edges"": [ | |
| { | |
| ""server_a_id"": 12, | |
| ""server_b_id"": 10 | |
| }, | |
| { | |
| ""server_a_id"": 12, | |
| ""server_b_id"": 13 | |
| }, | |
| { | |
| ""server_a_id"": 13, | |
| ""server_b_id"": 14 | |
| }, | |
| { | |
| ""server_a_id"": 14, | |
| ""server_b_id"": 15 | |
| }, | |
| { | |
| ""server_a_id"": 15, | |
| ""server_b_id"": 16 | |
| }, | |
| { | |
| ""server_a_id"": 16, | |
| ""server_b_id"": 17 | |
| }, | |
| { | |
| ""server_a_id"": 17, | |
| ""server_b_id"": 18 | |
| }, | |
| { | |
| ""server_a_id"": 18, | |
| ""server_b_id"": 19 | |
| }, | |
| { | |
| ""server_a_id"": 19, | |
| ""server_b_id"": 11 | |
| }, | |
| { | |
| ""server_a_id"": 11, | |
| ""server_b_id"": 1 | |
| }, | |
| { | |
| ""server_a_id"": 11, | |
| ""server_b_id"": 3 | |
| }, | |
| { | |
| ""server_a_id"": 0, | |
| ""server_b_id"": 4 | |
| }, | |
| { | |
| ""server_a_id"": 1, | |
| ""server_b_id"": 2 | |
| }, | |
| { | |
| ""server_a_id"": 2, | |
| ""server_b_id"": 3 | |
| }, | |
| { | |
| ""server_a_id"": 4, | |
| ""server_b_id"": 5 | |
| }, | |
| { | |
| ""server_a_id"": 5, | |
| ""server_b_id"": 6 | |
| }, | |
| { | |
| ""server_a_id"": 6, | |
| ""server_b_id"": 7 | |
| }, | |
| { | |
| ""server_a_id"": 7, | |
| ""server_b_id"": 8 | |
| }, | |
| { | |
| ""server_a_id"": 8, | |
| ""server_b_id"": 9 | |
| }, | |
| { | |
| ""server_a_id"": 9, | |
| ""server_b_id"": 10 | |
| } | |
| ] | |
| } | |
| When you're ready, just send back the selected hosts using this simple JSON shape: | |
| { | |
| ""solution"": [""server_id"", ""server_id"", ...] | |
| } | |
| This just means ""solution"" is a list of the server IDs where we'll put agents. The server_id entries above are just placeholders showing the format — replace them with the exact IDs from the instance when you answer. Think of it like filling in a short form: one array, a bunch of server names. | |
| This JSON is only a sketch of the shape I expect, not the actual answer. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 20, 'edges': [{'u': 13, 'v': 11}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 12}, {'u': 12, 'v': 2}, {'u': 12, 'v': 4}, {'u': 1, 'v': 5}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}], 'source_file': 'great-britain_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0005.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0005.png', 'edge_connectivity': 1}","[3, 5, 8, 11, 12, 15, 18]",7.0,"{'num_nodes': 20, 'num_edges': 20, 'edges': [{'u': 12, 'v': 10}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 11}, {'u': 11, 'v': 1}, {'u': 11, 'v': 3}, {'u': 0, 'v': 4}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}]}","[2, 4, 7, 10, 11, 14, 17]",6,json,0 | |
| MDS,MDS,"I’m coordinating camera placement across a patchwork of forest clearings and the idea is simple: pick a handful of clearings to install traps so that every clearing either has a camera or is visible from one that does. The choice to make is which clearings get cameras; a plan that uses fewer cameras is better — just count how many are installed and prefer the smaller number. Practically, every clearing must be covered (either host a camera or be next to a clearing with one) and each camera sits in one clearing and only counts once, so nothing can be left uncovered or double-counted. The exact map and clearing list are shown below. | |
| There are 24 clearings in total and 24 visibility links. | |
| | clearing_u_id | clearing_v_id | | |
| |---|---| | |
| | L | G | | |
| | L | M | | |
| | M | N | | |
| | N | O | | |
| | O | P | | |
| | P | Q | | |
| | Q | R | | |
| | R | S | | |
| | S | T | | |
| | T | U | | |
| | U | V | | |
| | V | A | | |
| | V | W | | |
| | W | X | | |
| | A | B | | |
| | B | C | | |
| | C | D | | |
| | D | E | | |
| | E | F | | |
| | F | G | | |
| | G | H | | |
| | H | I | | |
| | I | J | | |
| | J | K | | |
| When you send the plan back, just use a tiny JSON snippet so it's easy for me (and any tools) to read. A relaxed example of the shape I want is below. | |
| { | |
| ""solution"": [""clearing_id"", ""clearing_id"", ...] | |
| } | |
| Pretty straightforward: ""solution"" is the list of clearings where we'll put cameras — each entry should be the ID of a clearing from the instance. This JSON is just a sketch of the shape I expect, not the actual answer — replace the placeholder strings with the real clearing IDs. | |
| All identifiers must match the instance exactly — no renaming and no new labels. | |
| Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 24, 'edges': [{'u': 12, 'v': 7}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 1}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}], 'source_file': 'italy_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0006.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0006.png', 'edge_connectivity': 1}","[2, 4, 7, 10, 14, 17, 20, 23]",8.0,"{'num_nodes': 24, 'num_edges': 24, 'edges': [{'u': 'L', 'v': 'G'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'U'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'A'}, {'u': 'V', 'v': 'W'}, {'u': 'W', 'v': 'X'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}]}","['B', 'D', 'G', 'J', 'N', 'Q', 'T', 'W']",7,markdown_table,names | |
| MDS,MDS,"I’m the marketing manager trying to put together a small promo that reaches every shop in our network by placing displays in just a few spots — each store should either host a display or be right next to a store that does. The better plan is the one that uses fewer hosting stores, which you can tell simply by counting how many stores end up chosen; nothing can be left uncovered and picking the same store twice doesn’t change anything. The exact store map and numbers are shown below. | |
| { | |
| ""total_stores"": 19, | |
| ""total_store_connections"": 18, | |
| ""edges"": [ | |
| { | |
| ""store_a"": ""D"", | |
| ""store_b"": ""E"" | |
| }, | |
| { | |
| ""store_a"": ""E"", | |
| ""store_b"": ""F"" | |
| }, | |
| { | |
| ""store_a"": ""A"", | |
| ""store_b"": ""B"" | |
| }, | |
| { | |
| ""store_a"": ""A"", | |
| ""store_b"": ""K"" | |
| }, | |
| { | |
| ""store_a"": ""A"", | |
| ""store_b"": ""S"" | |
| }, | |
| { | |
| ""store_a"": ""B"", | |
| ""store_b"": ""C"" | |
| }, | |
| { | |
| ""store_a"": ""H"", | |
| ""store_b"": ""G"" | |
| }, | |
| { | |
| ""store_a"": ""H"", | |
| ""store_b"": ""I"" | |
| }, | |
| { | |
| ""store_a"": ""I"", | |
| ""store_b"": ""J"" | |
| }, | |
| { | |
| ""store_a"": ""J"", | |
| ""store_b"": ""K"" | |
| }, | |
| { | |
| ""store_a"": ""K"", | |
| ""store_b"": ""R"" | |
| }, | |
| { | |
| ""store_a"": ""G"", | |
| ""store_b"": ""F"" | |
| }, | |
| { | |
| ""store_a"": ""L"", | |
| ""store_b"": ""M"" | |
| }, | |
| { | |
| ""store_a"": ""M"", | |
| ""store_b"": ""N"" | |
| }, | |
| { | |
| ""store_a"": ""N"", | |
| ""store_b"": ""O"" | |
| }, | |
| { | |
| ""store_a"": ""O"", | |
| ""store_b"": ""P"" | |
| }, | |
| { | |
| ""store_a"": ""P"", | |
| ""store_b"": ""Q"" | |
| }, | |
| { | |
| ""store_a"": ""Q"", | |
| ""store_b"": ""R"" | |
| } | |
| ] | |
| } | |
| Oh, and when you send the solution back, just use a tiny JSON snippet like this so it's easy to check: | |
| { | |
| ""solution"": [""store_id"", ""store_id"", ...] | |
| } | |
| Think of ""solution"" as the list of stores where we'll put the displays — one entry per chosen store. This is just a sketch of the shape I need, not the actual plan itself. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| For example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 1, 'v': 2}, {'u': 1, 'v': 11}, {'u': 1, 'v': 19}, {'u': 2, 'v': 3}, {'u': 8, 'v': 7}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 18}, {'u': 7, 'v': 6}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}], 'source_file': 'netherlands_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0007.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0007.png', 'edge_connectivity': 1}","[1, 2, 5, 8, 11, 13, 16]",7.0,"{'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'A', 'v': 'B'}, {'u': 'A', 'v': 'K'}, {'u': 'A', 'v': 'S'}, {'u': 'B', 'v': 'C'}, {'u': 'H', 'v': 'G'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'R'}, {'u': 'G', 'v': 'F'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}]}","['A', 'B', 'E', 'H', 'K', 'M', 'P']",8,json,names | |
| MDS,MDS,"Recently a decision came up about placing water troughs across neighboring fields so every field either contains a trough or borders a field with one, and the goal is to do that with the least number of troughs. You rate any placement by the total number of troughs used — fewer troughs means a better solution. Make sure every field is covered by that choice and don’t waste resources by putting multiple troughs in the same field. The exact instance details are shown below. | |
| # total_fields=22 | |
| # total_borders=21 | |
| field_a_id,field_b_id | |
| 18,14 | |
| 2,13 | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 6,7 | |
| 6,17 | |
| 7,8 | |
| 8,0 | |
| 8,19 | |
| 9,12 | |
| 19,20 | |
| 10,1 | |
| 10,11 | |
| 10,21 | |
| 11,12 | |
| 11,13 | |
| 0,1 | |
| 14,15 | |
| 15,16 | |
| 16,17 | |
| Oh, and when you send the placement back, please use this simple JSON shape so it's easy to read and parse: | |
| { | |
| ""solution"": [""field_id"", ""field_id"", ...] | |
| } | |
| Think of ""solution"" as just a list of the fields where you put troughs — each placeholder like ""field_id"" stands in for one of the actual field identifiers from the instance. This is just a sketch of the shape I expect, not the real answer itself. | |
| Please make sure to use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 19, 'v': 15}, {'u': 3, 'v': 14}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 18}, {'u': 8, 'v': 9}, {'u': 9, 'v': 1}, {'u': 9, 'v': 20}, {'u': 10, 'v': 13}, {'u': 20, 'v': 21}, {'u': 11, 'v': 2}, {'u': 11, 'v': 12}, {'u': 11, 'v': 22}, {'u': 12, 'v': 13}, {'u': 12, 'v': 14}, {'u': 1, 'v': 2}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}], 'source_file': 'great-britain_osm.mtx', 'density': 0.09090909090909091, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0008.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0008.png', 'edge_connectivity': 1}","[5, 9, 11, 13, 14, 15, 18, 20]",8.0,"{'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 18, 'v': 14}, {'u': 2, 'v': 13}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 6, 'v': 17}, {'u': 7, 'v': 8}, {'u': 8, 'v': 0}, {'u': 8, 'v': 19}, {'u': 9, 'v': 12}, {'u': 19, 'v': 20}, {'u': 10, 'v': 1}, {'u': 10, 'v': 11}, {'u': 10, 'v': 21}, {'u': 11, 'v': 12}, {'u': 11, 'v': 13}, {'u': 0, 'v': 1}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}]}","[4, 8, 10, 12, 13, 14, 17, 19]",9,csv,0 | |
| MDS,MDS,"Back in the office, the superintendent sketched the hallways and asked: which apartments should store the extinguishers so that every unit either contains one or is connected by a hallway to a unit that does? The winning plan is simply the one with the fewest apartments actually storing extinguishers — judge any placement by that count — while making sure every apartment gets covered and avoiding putting extras where they don’t help. The exact building sketch is shown below. | |
| It shows 19 apartments and 18 hallway connections: | |
| Apartment 1 shares a hallway with apartment 2. | |
| Apartment 1 shares a hallway with apartment 7. | |
| Apartment 1 shares a hallway with apartment 8. | |
| Apartment 2 shares a hallway with apartment 3. | |
| Apartment 4 shares a hallway with apartment 5. | |
| Apartment 5 shares a hallway with apartment 6. | |
| Apartment 6 shares a hallway with apartment 7. | |
| Apartment 6 shares a hallway with apartment 17. | |
| Apartment 7 shares a hallway with apartment 16. | |
| Apartment 8 shares a hallway with apartment 9. | |
| Apartment 10 shares a hallway with apartment 11. | |
| Apartment 11 shares a hallway with apartment 12. | |
| Apartment 12 shares a hallway with apartment 13. | |
| Apartment 13 shares a hallway with apartment 14. | |
| Apartment 14 shares a hallway with apartment 15. | |
| Apartment 15 shares a hallway with apartment 18. | |
| Apartment 16 shares a hallway with apartment 18. | |
| Apartment 16 shares a hallway with apartment 19. | |
| Choose the fewest apartments to store extinguishers so every apartment is either storing one or adjacent to one; judge plans by that count. | |
| Oh — and when you give the final answer, please use a tiny JSON sketch like this so it's easy to check: | |
| { | |
| ""solution"": [""apartment_id"", ""apartment_id"", ...] | |
| } | |
| Think of ""solution"" as the list of apartment identifiers where the extinguishers should go — just the labels, nothing else. This block is just the expected shape (a simple list), not the actual placement. | |
| Please be careful to use the identifiers exactly as they appear in the instance input — no renaming, no made-up labels. | |
| for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 1, 'v': 2}, {'u': 1, 'v': 7}, {'u': 1, 'v': 8}, {'u': 2, 'v': 3}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 6, 'v': 17}, {'u': 7, 'v': 16}, {'u': 8, 'v': 9}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 18}, {'u': 16, 'v': 18}, {'u': 16, 'v': 19}], 'source_file': 'great-britain_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0009.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0009.png', 'edge_connectivity': 1}","[2, 5, 6, 8, 11, 14, 16]",7.0,"{'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 1, 'v': 2}, {'u': 1, 'v': 7}, {'u': 1, 'v': 8}, {'u': 2, 'v': 3}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 6, 'v': 17}, {'u': 7, 'v': 16}, {'u': 8, 'v': 9}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 18}, {'u': 16, 'v': 18}, {'u': 16, 'v': 19}]}","[2, 5, 6, 8, 11, 14, 16]",10,nl,1 | |
| MDS,MDS,"Someone in the control room needs to decide where to sit relays across the substations so every station either has one installed or is connected to a station that does. The goal is obvious: use as few relays as you can get away with — place them, count them, and make sure every substation ends up covered by a relay at its own site or at an adjacent site. Everything must be covered, and there’s no point in duplicating relays where a single one already serves the neighborhood. The concrete network details are listed below. | |
| There are 21 substations and 20 transmission lines: | |
| Substation 6 is connected to substation 3; a relay at either endpoint covers both. | |
| Substation 6 is connected to substation 7; a relay at either endpoint covers both. | |
| Substation 8 is connected to substation 9; a relay at either endpoint covers both. | |
| Substation 9 is connected to substation 10; a relay at either endpoint covers both. | |
| Substation 10 is connected to substation 18; a relay at either endpoint covers both. | |
| Substation 10 is connected to substation 19; a relay at either endpoint covers both. | |
| Substation 11 is connected to substation 12; a relay at either endpoint covers both. | |
| Substation 12 is connected to substation 13; a relay at either endpoint covers both. | |
| Substation 13 is connected to substation 14; a relay at either endpoint covers both. | |
| Substation 14 is connected to substation 5; a relay at either endpoint covers both. | |
| Substation 15 is connected to substation 5; a relay at either endpoint covers both. | |
| Substation 15 is connected to substation 16; a relay at either endpoint covers both. | |
| Substation 16 is connected to substation 17; a relay at either endpoint covers both. | |
| Substation 17 is connected to substation 18; a relay at either endpoint covers both. | |
| Substation 19 is connected to substation 20; a relay at either endpoint covers both. | |
| Substation 20 is connected to substation 21; a relay at either endpoint covers both. | |
| Substation 1 is connected to substation 2; a relay at either endpoint covers both. | |
| Substation 2 is connected to substation 3; a relay at either endpoint covers both. | |
| Substation 3 is connected to substation 4; a relay at either endpoint covers both. | |
| Substation 4 is connected to substation 5; a relay at either endpoint covers both. | |
| Place relays so all 21 substations end up covered with as few relays as possible. | |
| Oh, and when you send the answer back, please stick to this simple JSON layout so the control room can read it automatically: | |
| { | |
| ""solution"": [""substation_id"", ""substation_id"", ...] | |
| } | |
| Pretty straightforward: ""solution"" is the list of substations where you put relays, and each entry in that array is the exact substation identifier from the instance (one per relay location). Think of it like filling out a short checklist — just the IDs of the places you chose. | |
| This is just the shape I expect, not the actual answer — replace those placeholders with the real IDs from the instance. All identifiers must be used exactly as they appear in the input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 6, 'v': 3}, {'u': 6, 'v': 7}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 18}, {'u': 10, 'v': 19}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 5}, {'u': 15, 'v': 5}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}], 'source_file': 'belgium_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0010.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0010.png', 'edge_connectivity': 1}","[2, 5, 6, 9, 12, 17, 20]",7.0,"{'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 6, 'v': 3}, {'u': 6, 'v': 7}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 18}, {'u': 10, 'v': 19}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 5}, {'u': 15, 'v': 5}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}]}","[2, 5, 6, 9, 12, 17, 20]",11,nl,1 | |
| MDS,MDS,"Someone in charge of station duty must decide which stops should have attendants so every stop is either staffed or next door to a staffed stop, and the aim is to keep the total number of attendants as low as possible. Plans are compared by tallying the attendants required; fewer attendants means a better plan. Practical rule: every station needs at least one nearby attendant, and nothing can be ignored when checking coverage. The specific instance and map follow below. | |
| For this instance there are 21 stations and 26 adjacency pairs; the map's adjacency list follows. | |
| Station 9 is adjacent to station 1; staffing either one covers the other. | |
| Station 9 is adjacent to station 14; staffing either one covers the other. | |
| Station 10 is adjacent to station 11; staffing either one covers the other. | |
| Station 10 is adjacent to station 12; staffing either one covers the other. | |
| Station 10 is adjacent to station 20; staffing either one covers the other. | |
| Station 12 is adjacent to station 13; staffing either one covers the other. | |
| Station 12 is adjacent to station 16; staffing either one covers the other. | |
| Station 12 is adjacent to station 17; staffing either one covers the other. | |
| Station 21 is adjacent to station 3; staffing either one covers the other. | |
| Station 13 is adjacent to station 5; staffing either one covers the other. | |
| Station 13 is adjacent to station 18; staffing either one covers the other. | |
| Station 15 is adjacent to station 14; staffing either one covers the other. | |
| Station 15 is adjacent to station 16; staffing either one covers the other. | |
| Station 16 is adjacent to station 18; staffing either one covers the other. | |
| Station 17 is adjacent to station 6; staffing either one covers the other. | |
| Station 17 is adjacent to station 20; staffing either one covers the other. | |
| Station 18 is adjacent to station 3; staffing either one covers the other. | |
| Station 18 is adjacent to station 4; staffing either one covers the other. | |
| Station 19 is adjacent to station 20; staffing either one covers the other. | |
| Station 2 is adjacent to station 3; staffing either one covers the other. | |
| Station 2 is adjacent to station 4; staffing either one covers the other. | |
| Station 3 is adjacent to station 1; staffing either one covers the other. | |
| Station 4 is adjacent to station 5; staffing either one covers the other. | |
| Station 5 is adjacent to station 6; staffing either one covers the other. | |
| Station 6 is adjacent to station 7; staffing either one covers the other. | |
| Station 7 is adjacent to station 8; staffing either one covers the other. | |
| The person in charge should verify that every one of the 21 stations is either staffed or adjacent to a staffed station, using the 26 pairs above to check coverage. | |
| When you're ready, just give me the chosen stops in a tiny JSON object like this: | |
| { | |
| ""solution"": [""stop_id"", ""stop_id"", ...] | |
| } | |
| Pretty simple: ""solution"" is the list of stops where attendants will be placed. Each string in that array is the identifier of a stop (one entry per staffed stop). This is just the expected shape — a sketch of the format, not the actual plan itself. | |
| Please make sure to use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 26, 'edges': [{'u': 9, 'v': 1}, {'u': 9, 'v': 14}, {'u': 10, 'v': 11}, {'u': 10, 'v': 12}, {'u': 10, 'v': 20}, {'u': 12, 'v': 13}, {'u': 12, 'v': 16}, {'u': 12, 'v': 17}, {'u': 21, 'v': 3}, {'u': 13, 'v': 5}, {'u': 13, 'v': 18}, {'u': 15, 'v': 14}, {'u': 15, 'v': 16}, {'u': 16, 'v': 18}, {'u': 17, 'v': 6}, {'u': 17, 'v': 20}, {'u': 18, 'v': 3}, {'u': 18, 'v': 4}, {'u': 19, 'v': 20}, {'u': 2, 'v': 3}, {'u': 2, 'v': 4}, {'u': 3, 'v': 1}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.12380952380952381, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0011.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0011.png', 'edge_connectivity': 1}","[3, 5, 7, 10, 14, 15, 20]",7.0,"{'num_nodes': 21, 'num_edges': 26, 'edges': [{'u': 9, 'v': 1}, {'u': 9, 'v': 14}, {'u': 10, 'v': 11}, {'u': 10, 'v': 12}, {'u': 10, 'v': 20}, {'u': 12, 'v': 13}, {'u': 12, 'v': 16}, {'u': 12, 'v': 17}, {'u': 21, 'v': 3}, {'u': 13, 'v': 5}, {'u': 13, 'v': 18}, {'u': 15, 'v': 14}, {'u': 15, 'v': 16}, {'u': 16, 'v': 18}, {'u': 17, 'v': 6}, {'u': 17, 'v': 20}, {'u': 18, 'v': 3}, {'u': 18, 'v': 4}, {'u': 19, 'v': 20}, {'u': 2, 'v': 3}, {'u': 2, 'v': 4}, {'u': 3, 'v': 1}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}]}","[3, 5, 7, 10, 14, 15, 20]",12,nl,1 | |
| MDS,MDS,"There’s a grid of stops across town, and the job is to mark a few of them as central drop-off hubs so every stop is either a hub or has a hub right next to it. What’s at stake is choosing which stops become hubs; a smarter choice is simply the one that uses the smallest number of hubs — you measure that by counting how many hubs you picked. No stop can be left out, and a hub shouldn’t be counted twice. The detailed layout is shown below. | |
| { | |
| ""total_stops"": 20, | |
| ""adjacency_count"": 19, | |
| ""edges"": [ | |
| { | |
| ""stop_u"": ""Q"", | |
| ""stop_v"": ""O"" | |
| }, | |
| { | |
| ""stop_u"": ""Q"", | |
| ""stop_v"": ""R"" | |
| }, | |
| { | |
| ""stop_u"": ""R"", | |
| ""stop_v"": ""L"" | |
| }, | |
| { | |
| ""stop_u"": ""S"", | |
| ""stop_v"": ""D"" | |
| }, | |
| { | |
| ""stop_u"": ""S"", | |
| ""stop_v"": ""E"" | |
| }, | |
| { | |
| ""stop_u"": ""A"", | |
| ""stop_v"": ""M"" | |
| }, | |
| { | |
| ""stop_u"": ""T"", | |
| ""stop_v"": ""M"" | |
| }, | |
| { | |
| ""stop_u"": ""B"", | |
| ""stop_v"": ""C"" | |
| }, | |
| { | |
| ""stop_u"": ""C"", | |
| ""stop_v"": ""E"" | |
| }, | |
| { | |
| ""stop_u"": ""C"", | |
| ""stop_v"": ""P"" | |
| }, | |
| { | |
| ""stop_u"": ""J"", | |
| ""stop_v"": ""I"" | |
| }, | |
| { | |
| ""stop_u"": ""J"", | |
| ""stop_v"": ""K"" | |
| }, | |
| { | |
| ""stop_u"": ""E"", | |
| ""stop_v"": ""F"" | |
| }, | |
| { | |
| ""stop_u"": ""F"", | |
| ""stop_v"": ""G"" | |
| }, | |
| { | |
| ""stop_u"": ""G"", | |
| ""stop_v"": ""H"" | |
| }, | |
| { | |
| ""stop_u"": ""H"", | |
| ""stop_v"": ""I"" | |
| }, | |
| { | |
| ""stop_u"": ""K"", | |
| ""stop_v"": ""L"" | |
| }, | |
| { | |
| ""stop_u"": ""K"", | |
| ""stop_v"": ""N"" | |
| }, | |
| { | |
| ""stop_u"": ""L"", | |
| ""stop_v"": ""M"" | |
| } | |
| ] | |
| } | |
| Oh, and when you send the picks back, please use this little JSON shape so it's easy to check: | |
| { | |
| ""solution"": [""stop_id"", ""stop_id"", ...] | |
| } | |
| Think of it like a simple form: ""solution"" is the list of stops you've marked as hubs (the placeholders above just show the shape). Fill that array with the exact stop identifiers from the instance — don't invent new names or change them. | |
| Also, please use the identifiers exactly as they appear in the input — no renaming. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”. | |
| The JSON above is just a sketch of the expected shape, not the actual answer.","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 17, 'v': 15}, {'u': 17, 'v': 18}, {'u': 18, 'v': 12}, {'u': 19, 'v': 4}, {'u': 19, 'v': 5}, {'u': 1, 'v': 13}, {'u': 20, 'v': 13}, {'u': 2, 'v': 3}, {'u': 3, 'v': 5}, {'u': 3, 'v': 16}, {'u': 10, 'v': 9}, {'u': 10, 'v': 11}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 11, 'v': 12}, {'u': 11, 'v': 14}, {'u': 12, 'v': 13}], 'source_file': 'great-britain_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0012.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0012.png', 'edge_connectivity': 1}","[3, 7, 8, 11, 13, 17, 19]",7.0,"{'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 'Q', 'v': 'O'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'L'}, {'u': 'S', 'v': 'D'}, {'u': 'S', 'v': 'E'}, {'u': 'A', 'v': 'M'}, {'u': 'T', 'v': 'M'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'E'}, {'u': 'C', 'v': 'P'}, {'u': 'J', 'v': 'I'}, {'u': 'J', 'v': 'K'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'K', 'v': 'L'}, {'u': 'K', 'v': 'N'}, {'u': 'L', 'v': 'M'}]}","['C', 'G', 'H', 'K', 'M', 'Q', 'S']",13,json,names | |
| MDS,MDS,"Many people in the community want a lean, efficient set of neighborhood leads so resources aren’t wasted, meaning each neighborhood must either have a lead or be adjacent to one. The choice is which neighborhoods get the leads; better choices cover the whole community using the fewest leads possible. To evaluate options, simply count how many leads a setup uses and make sure no neighborhood is left out or assigned twice — choose the setup with the smallest number that still provides full coverage. The concrete details will be shown below. | |
| There are 25 neighborhoods and 25 bordering pairs to consider. | |
| Neighborhood L borders neighborhood M. | |
| Neighborhood M borders neighborhood N. | |
| Neighborhood N borders neighborhood O. | |
| Neighborhood O borders neighborhood P. | |
| Neighborhood P borders neighborhood Q. | |
| Neighborhood Q borders neighborhood F. | |
| Neighborhood Q borders neighborhood R. | |
| Neighborhood R borders neighborhood S. | |
| Neighborhood S borders neighborhood T. | |
| Neighborhood T borders neighborhood U. | |
| Neighborhood U borders neighborhood V. | |
| Neighborhood V borders neighborhood W. | |
| Neighborhood X borders neighborhood W. | |
| Neighborhood X borders neighborhood Y. | |
| Neighborhood Y borders neighborhood C. | |
| Neighborhood A borders neighborhood B. | |
| Neighborhood B borders neighborhood C. | |
| Neighborhood C borders neighborhood D. | |
| Neighborhood D borders neighborhood E. | |
| Neighborhood E borders neighborhood F. | |
| Neighborhood F borders neighborhood G. | |
| Neighborhood G borders neighborhood H. | |
| Neighborhood H borders neighborhood I. | |
| Neighborhood I borders neighborhood J. | |
| Neighborhood J borders neighborhood K. | |
| Choose lead placements that cover all 25 neighborhoods using the fewest leads possible. | |
| When you’re ready to reply, just drop the chosen neighborhoods into a tiny JSON object like this: | |
| { | |
| ""solution"": [""neighborhood_id"", ""neighborhood_id"", ...] | |
| } | |
| ""solution"" is just a list of the neighborhood IDs you want to assign leads to — nothing fancy. Think of it like a short form: each item is a neighborhood label from the instance input, listed one after another. This JSON is only a sketch of the expected shape, not the actual answer — replace those placeholders with the real IDs from the instance. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 6}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 24, 'v': 23}, {'u': 24, 'v': 25}, {'u': 25, 'v': 3}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}], 'source_file': 'italy_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0013.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0013.png', 'edge_connectivity': 1}","[2, 5, 7, 10, 13, 16, 19, 21, 24]",9.0,"{'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'F'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'U'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'W'}, {'u': 'X', 'v': 'W'}, {'u': 'X', 'v': 'Y'}, {'u': 'Y', 'v': 'C'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}]}","['B', 'E', 'G', 'J', 'M', 'P', 'S', 'U', 'X']",14,nl,names | |
| MDS,MDS,"Recently the committee talked about cutting down on tent clutter: pick tent locations so every area either hosts an information tent or is adjacent to one. The cleanest solution is the one with the fewest tents — simply count how many tents are used and prefer the lower total. No area can be ignored, and tents shouldn’t be duplicated in the same spot. The detailed map and area list are provided below. | |
| # total_areas=25 | |
| # total_adjacency_links=24 | |
| area_a_id,area_b_id | |
| 19,18 | |
| 19,20 | |
| 20,21 | |
| 21,22 | |
| 22,23 | |
| 23,24 | |
| 24,25 | |
| 1,2 | |
| 2,3 | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 6,7 | |
| 7,8 | |
| 8,9 | |
| 9,10 | |
| 10,11 | |
| 11,12 | |
| 12,13 | |
| 13,14 | |
| 14,15 | |
| 15,16 | |
| 16,17 | |
| 17,18 | |
| Also, when you send the final pick, please stick to this little JSON layout so it's easy to read and use. | |
| { | |
| ""solution"": [""area_id"", ""area_id"", ...] | |
| } | |
| Here ""solution"" is just the list of areas where we'll put tents — each string is an area identifier from the map. Think of it like copying the spot labels into a form: nothing fancy, just the IDs. This JSON is only a sketch of the shape I expect, not the actual answer. | |
| Please make sure to use the identifiers exactly as they appear in the instance input — no renaming and no inventing new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 19, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 24, 'v': 25}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.08, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0014.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0014.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 13, 15, 18, 21, 24]",9.0,"{'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 19, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 24, 'v': 25}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}]}","[2, 5, 8, 11, 13, 15, 18, 21, 24]",15,csv,1 | |
| MDS,MDS,"Recently the IT team decided to limit installs and only put antivirus where it’s really needed, so every workstation either has protection or is on the same subnet/connection to one that does. The decision is figuring out which few machines get the software — the best pick is the one with the smallest number of installs that still reaches every device. To check any choice, simply add up the installed machines and verify each remaining machine is directly linked to at least one of them; fewer installations are better, and nothing can be missed or installed multiple times for no reason. The office diagram and exact device links are shown below. | |
| There are 25 workstations in total and 24 network connections. | |
| | computer_endpoint_u | computer_endpoint_v | | |
| |---|---| | |
| | 19 | 15 | | |
| | 19 | 20 | | |
| | 20 | 23 | | |
| | 0 | 1 | | |
| | 1 | 2 | | |
| | 1 | 24 | | |
| | 2 | 3 | | |
| | 2 | 18 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 21 | 22 | | |
| | 22 | 23 | | |
| Oh, and when you give the final pick, please use this simple JSON layout so it's easy to check programmatically — nothing fancy, just a list of the machines you choose: | |
| { | |
| ""solution"": [""machine_id"", ""machine_id"", ...] | |
| } | |
| Here ""solution"" should be filled with the identifiers of the workstations that will get the antivirus installed — just a plain list of those machine IDs. Think of it like a short form: put each machine's exact label in the array, and that's your answer. This JSON is just a sketch of the shape I expect, not the actual solution. | |
| Please make sure you use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 20, 'v': 16}, {'u': 20, 'v': 21}, {'u': 21, 'v': 24}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 2, 'v': 25}, {'u': 3, 'v': 4}, {'u': 3, 'v': 19}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.08, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0015.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0015.png', 'edge_connectivity': 1}","[2, 3, 6, 9, 11, 14, 17, 20, 23]",9.0,"{'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 19, 'v': 15}, {'u': 19, 'v': 20}, {'u': 20, 'v': 23}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 1, 'v': 24}, {'u': 2, 'v': 3}, {'u': 2, 'v': 18}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}]}","[1, 2, 5, 8, 10, 13, 16, 19, 22]",16,markdown_table,0 | |
| MDS,MDS,"I’m helping coordinate a small patrol network where the trick is to name as few houses as possible as bases, with the rule that every house must either be a base or have a base next door. A better selection is the one that uses the fewest bases while still touching every house; to check it, count the bases and walk the map to ensure each home is covered. No house can be left out and bases should be distinct. The concrete layout and house numbers come next below. | |
| There are 20 houses in total and 19 adjacency pairs. | |
| | house_one | house_two | | |
| |---|---| | |
| | D | C | | |
| | D | E | | |
| | E | F | | |
| | G | C | | |
| | G | H | | |
| | H | I | | |
| | I | J | | |
| | J | K | | |
| | K | L | | |
| | A | B | | |
| | L | M | | |
| | M | N | | |
| | N | O | | |
| | O | P | | |
| | P | Q | | |
| | Q | R | | |
| | C | B | | |
| | R | S | | |
| | S | T | | |
| When you’re ready, just send back a tiny JSON snippet in this shape so I can read which houses you picked as bases: | |
| { | |
| ""solution"": [""house_id"", ""house_id"", ...] | |
| } | |
| Think of ""solution"" as the list of house IDs you want to name as bases — one entry per chosen house. This is just a sketch of the shape I need, not the actual answer. | |
| Please be careful to use the identifiers exactly as they appear in the instance input — don’t rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 4, 'v': 3}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 7, 'v': 3}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 1, 'v': 2}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 3, 'v': 2}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}], 'source_file': 'great-britain_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0016.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0016.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 13, 16, 19]",7.0,"{'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 'D', 'v': 'C'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'G', 'v': 'C'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'A', 'v': 'B'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'C', 'v': 'B'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}]}","['B', 'E', 'H', 'K', 'M', 'P', 'S']",17,markdown_table,names | |
| MDS,MDS,"Many people on the team keep asking the same question: which few stores should host demos so that every location is either a host or right next to a host, while keeping the total number of hosts as low as possible. You compare options by the total number of chosen stores — the lower that number, the better — and it’s required that every store is covered and none are selected more than once. The specific details follow below. | |
| There are 19 stores and 18 adjacency pairs listed below: | |
| Store F is adjacent to store G; hosting at either covers the other. | |
| Store G is adjacent to store H; hosting at either covers the other. | |
| Store H is adjacent to store D; hosting at either covers the other. | |
| Store I is adjacent to store D; hosting at either covers the other. | |
| Store I is adjacent to store J; hosting at either covers the other. | |
| Store J is adjacent to store K; hosting at either covers the other. | |
| Store K is adjacent to store L; hosting at either covers the other. | |
| Store L is adjacent to store M; hosting at either covers the other. | |
| Store M is adjacent to store N; hosting at either covers the other. | |
| Store N is adjacent to store O; hosting at either covers the other. | |
| Store O is adjacent to store P; hosting at either covers the other. | |
| Store P is adjacent to store Q; hosting at either covers the other. | |
| Store Q is adjacent to store R; hosting at either covers the other. | |
| Store D is adjacent to store C; hosting at either covers the other. | |
| Store C is adjacent to store B; hosting at either covers the other. | |
| Store R is adjacent to store S; hosting at either covers the other. | |
| Store S is adjacent to store E; hosting at either covers the other. | |
| Store B is adjacent to store A; hosting at either covers the other. | |
| Use these 18 adjacency pairs to ensure coverage of all 19 stores. | |
| Also, when you send back the chosen stores, please use a tiny JSON layout so it's easy to read and parse. For this demo-hosting question, something like this is what I expect: | |
| { | |
| ""solution"": [""store_id"", ""store_id"", ...] | |
| } | |
| ""solution"" is just the list of stores you've picked to host demos — one identifier per entry. That JSON is only a template showing the shape I want; don't treat ""store_id"" as a real ID. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no invented labels. Valid identifiers look like: | |
| - plain numbers such as “1” or “23” | |
| - single capital letters like “A” or “B” | |
| - a capital letter followed by digits like “A1” or “X7”","{'problem_type': 'MDS', 'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 4}, {'u': 9, 'v': 4}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 4, 'v': 3}, {'u': 3, 'v': 2}, {'u': 18, 'v': 19}, {'u': 19, 'v': 5}, {'u': 2, 'v': 1}], 'source_file': 'great-britain_osm.mtx', 'density': 0.10526315789473684, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0017.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0017.png', 'edge_connectivity': 1}","[2, 7, 9, 12, 13, 16, 19]",7.0,"{'num_nodes': 19, 'num_edges': 18, 'edges': [{'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'D'}, {'u': 'I', 'v': 'D'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'D', 'v': 'C'}, {'u': 'C', 'v': 'B'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'E'}, {'u': 'B', 'v': 'A'}]}","['B', 'G', 'I', 'L', 'M', 'P', 'S']",18,nl,names | |
| MDS,MDS,"On a busy afternoon the admin team realized the hospital could improve infection control by placing sanitizer stations so that every ward is either fitted with one or directly next to a ward that is. The aim is to cover every ward but do it with the fewest dispensers possible — fewer dispensers that still reach every ward is the preferred setup. To validate a layout, count the dispensers and ensure every ward has coverage; duplicating dispensers in the same ward without covering new wards should be avoided. The specific layout and numbers are shown below. | |
| # total_wards_count=25 | |
| # adjacent_ward_pairs_count=25 | |
| ward_endpoint_a,ward_endpoint_b | |
| 13,11 | |
| 14,3 | |
| 15,3 | |
| 16,2 | |
| 17,2 | |
| 17,18 | |
| 19,1 | |
| 20,1 | |
| 20,21 | |
| 22,10 | |
| 22,23 | |
| 23,9 | |
| 23,24 | |
| 7,6 | |
| 7,8 | |
| 9,6 | |
| 9,10 | |
| 10,0 | |
| 11,0 | |
| 11,12 | |
| 5,6 | |
| 0,1 | |
| 1,2 | |
| 2,3 | |
| 3,4 | |
| Also, just so everything is machine-friendly, please send the proposed dispenser locations using this simple JSON shape: | |
| { | |
| ""solution"": [""ward_id"", ""ward_id"", ...] | |
| } | |
| Here ""solution"" is just a list of the ward identifiers where you'd place sanitizer stations — think of each entry as the label for a ward (it’s a sketch of the shape I expect, not the actual answer). Use the identifiers exactly as they appear in the instance input — don’t rename them or invent new labels. | |
| Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 14, 'v': 12}, {'u': 15, 'v': 4}, {'u': 16, 'v': 4}, {'u': 17, 'v': 3}, {'u': 18, 'v': 3}, {'u': 18, 'v': 19}, {'u': 20, 'v': 2}, {'u': 21, 'v': 2}, {'u': 21, 'v': 22}, {'u': 23, 'v': 11}, {'u': 23, 'v': 24}, {'u': 24, 'v': 10}, {'u': 24, 'v': 25}, {'u': 8, 'v': 7}, {'u': 8, 'v': 9}, {'u': 10, 'v': 7}, {'u': 10, 'v': 11}, {'u': 11, 'v': 1}, {'u': 12, 'v': 1}, {'u': 12, 'v': 13}, {'u': 6, 'v': 7}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}], 'source_file': 'italy_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0018.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0018.png', 'edge_connectivity': 1}","[1, 2, 3, 4, 7, 8, 12, 18, 21, 24]",10.0,"{'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 13, 'v': 11}, {'u': 14, 'v': 3}, {'u': 15, 'v': 3}, {'u': 16, 'v': 2}, {'u': 17, 'v': 2}, {'u': 17, 'v': 18}, {'u': 19, 'v': 1}, {'u': 20, 'v': 1}, {'u': 20, 'v': 21}, {'u': 22, 'v': 10}, {'u': 22, 'v': 23}, {'u': 23, 'v': 9}, {'u': 23, 'v': 24}, {'u': 7, 'v': 6}, {'u': 7, 'v': 8}, {'u': 9, 'v': 6}, {'u': 9, 'v': 10}, {'u': 10, 'v': 0}, {'u': 11, 'v': 0}, {'u': 11, 'v': 12}, {'u': 5, 'v': 6}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}]}","[0, 1, 2, 3, 6, 7, 11, 17, 20, 23]",19,csv,0 | |
| MDS,MDS,"We’re figuring out where to place a handful of information signs around the park so that every crossroads is either fitted with a sign or touches a crossroads that has one. The trick is to pick spots so the total number of signs is as small as it can be while still making sure every junction is covered. To evaluate any layout, tally the signs and make sure every junction is either hosting a sign or next to one — don’t leave any junction without coverage and avoid redundant double-signs at the same place. The specific map and details are shown below. | |
| # num_junctions=24 | |
| # num_trail_segments=23 | |
| junction_a,junction_b | |
| 21,20 | |
| 22,20 | |
| 22,23 | |
| 0,1 | |
| 1,2 | |
| 2,3 | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 6,7 | |
| 7,8 | |
| 8,9 | |
| 9,10 | |
| 10,11 | |
| 11,12 | |
| 12,13 | |
| 13,14 | |
| 14,15 | |
| 15,16 | |
| 16,17 | |
| 17,18 | |
| 18,19 | |
| 19,20 | |
| When you send the layout back, please keep it in a tiny JSON shape so it's easy to check. Just like this: | |
| { | |
| ""solution"": [""junction_id"", ""junction_id"", ...] | |
| } | |
| Pretty simple: the ""solution"" array lists the crossroads (junctions) where you'd put the signs. Think of it like filling out a short form — each entry is the exact junction identifier you choose. The snippet above is just a sketch of the shape I expect, not the actual answer. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: Valid identifiers look like plain numbers such as ""1"" or ""23"", single capital letters like ""A"" or ""B"", or a capital letter followed by digits like ""A1"" or ""X7"".","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 22, 'v': 21}, {'u': 23, 'v': 21}, {'u': 23, 'v': 24}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}], 'source_file': 'italy_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0019.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0019.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 12, 15, 18, 21, 23]",9.0,"{'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 21, 'v': 20}, {'u': 22, 'v': 20}, {'u': 22, 'v': 23}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}]}","[1, 4, 7, 10, 11, 14, 17, 20, 22]",20,csv,0 | |
| MDS,MDS,"Someone in charge needs to name a few volunteer homes so that every residence either has a volunteer living there or sits beside one that does. A smarter choice uses fewer host households — count the hosts to see which plan is better. It’s mandatory that every house be covered by hosting or adjacency, and there’s no duplicating a host entry. The specific neighborhood layout appears below. | |
| # total_houses=21 | |
| # total_adjacent_pairs=20 | |
| house_u,house_v | |
| A,B | |
| B,C | |
| C,D | |
| D,E | |
| E,F | |
| F,G | |
| G,H | |
| H,I | |
| I,J | |
| J,K | |
| K,L | |
| L,M | |
| M,N | |
| N,O | |
| O,P | |
| P,Q | |
| Q,R | |
| R,S | |
| S,T | |
| T,U | |
| Also, when you send the pick of volunteer homes, it helps if you put it in a tiny JSON snippet like this so it's easy to read and check. | |
| { | |
| ""solution"": [""house_id"", ""house_id"", ...] | |
| } | |
| Here that ""solution"" list is just the set of homes you'll ask to host — a simple list of the house labels you choose. It's just a sketch of the format I want, not the actual answer itself. | |
| Please make sure to use the exact identifiers given in the instance input — don't rename them or invent new ones. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}], 'source_file': 'great-britain_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0020.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0020.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 14, 17, 20]",7.0,"{'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'U'}]}","['B', 'E', 'H', 'K', 'N', 'Q', 'T']",21,csv,names | |
| MDS,MDS,"Many warehouses face the same puzzle: decide which bays get monitoring so every bay is either watched directly or has a watched neighbor on its aisle. The better the solution, the fewer monitored bays it uses — the count of chosen bays is the simple measure of success. Every bay must be covered in one of those two ways, and picking one bay more than once doesn’t change the count. The exact layout and data are shown below. | |
| There are 20 storage bays in total and 19 aisle connections. | |
| | bay_a | bay_b | | |
| |---|---| | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 9 | 11 | | |
| | 10 | 16 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 13 | 19 | | |
| | 15 | 0 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 17 | 18 | | |
| Also, when you send your chosen bays, it's easiest if you put them in a small JSON snippet like this: | |
| { | |
| ""solution"": [""bay_id"", ""bay_id"", ...] | |
| } | |
| Here, ""solution"" is just the list of bay identifiers you'd pick to monitor — think of each entry as the label of a bay you'd mark for watching. This block is just a sketch of the shape I want the answer in, not the actual solution. | |
| Please use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 10, 'v': 12}, {'u': 11, 'v': 17}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 14, 'v': 20}, {'u': 16, 'v': 1}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}], 'source_file': 'belgium_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0021.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0021.png', 'edge_connectivity': 1}","[3, 6, 9, 10, 14, 16, 18]",7.0,"{'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 9, 'v': 11}, {'u': 10, 'v': 16}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 13, 'v': 19}, {'u': 15, 'v': 0}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}]}","[2, 5, 8, 9, 13, 15, 17]",22,markdown_table,0 | |
| MDS,MDS,"Back when the principal was reorganizing supervision, the task was to pick some classrooms to act as the leads so every classroom is either one of those leads or right next to one. The better arrangement uses the fewest lead classrooms — you just add up the chosen leads to see how well it did, aiming for the lowest total. Every classroom must be covered, and no classroom should be picked more than once. The detailed list of classrooms is shown below. | |
| # total_classrooms=22 | |
| # total_adjacent_pairs=21 | |
| adjacent_classroom_a,adjacent_classroom_b | |
| 9,8 | |
| 9,10 | |
| 10,11 | |
| 11,12 | |
| 12,13 | |
| 13,14 | |
| 13,20 | |
| 20,21 | |
| 15,3 | |
| 15,16 | |
| 16,17 | |
| 17,18 | |
| 18,19 | |
| 19,2 | |
| 0,1 | |
| 1,2 | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 6,7 | |
| 7,8 | |
| If you're going to give the answer, just stick to a tiny JSON snippet like this — keeps things tidy and machine-friendly, but nothing fussy: | |
| { | |
| ""solution"": [""classroom_id"", ""classroom_id"", ...] | |
| } | |
| Here ""solution"" is the list of chosen lead classrooms (the ones you picked so every classroom is either a lead or right next to one). The items in the array are the classroom identifiers — just list each one exactly as shown in the instance. This is only a sketch of the shape I expect, not the actual answer. | |
| Please use the exact identifiers from the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 10, 'v': 9}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 14, 'v': 21}, {'u': 21, 'v': 22}, {'u': 16, 'v': 4}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 3}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.09090909090909091, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0022.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0022.png', 'edge_connectivity': 1}","[2, 6, 8, 11, 14, 16, 19, 21]",8.0,"{'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 9, 'v': 8}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 13, 'v': 20}, {'u': 20, 'v': 21}, {'u': 15, 'v': 3}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 2}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}]}","[1, 5, 7, 10, 13, 15, 18, 20]",23,csv,0 | |
| MDS,MDS,"Recently the ops crew needed to schedule maintenance with minimal impact, so the plan was to pick a small set of hosts to run maintenance and let their direct neighbors ride on that coverage. The decision is which hosts to pick; the preferred plan is the one that covers every server while using as few maintenance hosts as possible. To evaluate any plan, count how many hosts were put into maintenance — that number should be as low as it can go — and double-check that every server is either in maintenance or directly connected to one, with no servers overlooked or duplicated. The detailed instance follows below. | |
| There are 24 servers in total and 24 links. | |
| | server_u | server_v | | |
| |---|---| | |
| | 20 | 19 | | |
| | 21 | 22 | | |
| | 22 | 14 | | |
| | 23 | 6 | | |
| | 23 | 24 | | |
| | 1 | 2 | | |
| | 1 | 10 | | |
| | 1 | 13 | | |
| | 1 | 14 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 7 | 18 | | |
| | 9 | 10 | | |
| | 10 | 19 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 19 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 17 | 18 | | |
| Also, when you send the plan back, just use a tiny JSON snippet like this so it's easy to read and machine-friendly: | |
| { | |
| ""solution"": [""host_id"", ""host_id"", ...] | |
| } | |
| Think of ""solution"" as the short checklist of hosts you picked for maintenance — just drop each host's identifier into that array. This JSON is only a sketch of the shape I expect, not the actual answer itself. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 24, 'edges': [{'u': 20, 'v': 19}, {'u': 21, 'v': 22}, {'u': 22, 'v': 14}, {'u': 23, 'v': 6}, {'u': 23, 'v': 24}, {'u': 1, 'v': 2}, {'u': 1, 'v': 10}, {'u': 1, 'v': 13}, {'u': 1, 'v': 14}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 18}, {'u': 9, 'v': 10}, {'u': 10, 'v': 19}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 19}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}], 'source_file': 'belgium_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0023.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0023.png', 'edge_connectivity': 1}","[3, 4, 7, 10, 12, 15, 18, 19, 22, 23]",10.0,"{'num_nodes': 24, 'num_edges': 24, 'edges': [{'u': 20, 'v': 19}, {'u': 21, 'v': 22}, {'u': 22, 'v': 14}, {'u': 23, 'v': 6}, {'u': 23, 'v': 24}, {'u': 1, 'v': 2}, {'u': 1, 'v': 10}, {'u': 1, 'v': 13}, {'u': 1, 'v': 14}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 18}, {'u': 9, 'v': 10}, {'u': 10, 'v': 19}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 19}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}]}","[3, 4, 7, 10, 12, 15, 18, 19, 22, 23]",24,markdown_table,1 | |
| MDS,MDS,"Recently a neighbor described a lazy farmer’s puzzle: put scarecrows on some plots so every plot either contains one or touches a plot with one. The aim is to manage complete coverage while minimizing how many scarecrows go up — fewer is better. To verify a plan, simply tally the scarecrows and ensure every plot either has one or is adjacent to one. Every plot must be covered, and extra scarecrows on the same plot don’t change anything. The specific instance is listed below. | |
| # total_plots=23 | |
| # adjacency_count=22 | |
| plot_id_1,plot_id_2 | |
| D,E | |
| E,A | |
| F,A | |
| F,G | |
| G,H | |
| H,I | |
| H,P | |
| I,J | |
| J,K | |
| J,M | |
| M,N | |
| N,O | |
| A,B | |
| B,C | |
| K,L | |
| P,Q | |
| Q,R | |
| Q,W | |
| R,S | |
| S,T | |
| U,V | |
| V,W | |
| If you'd like to propose a plan, you can just give it in a tiny JSON object — nothing fancy. Here’s the shape I expect: | |
| { | |
| ""solution"": [""plot_id"", ""plot_id"", ...] | |
| } | |
| Think of ""solution"" as the list of plots where you'd put scarecrows — each item is one plot identifier from the instance. This is just a sketch of the form I want, not the actual answer. | |
| Please use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 4, 'v': 5}, {'u': 5, 'v': 1}, {'u': 6, 'v': 1}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 8, 'v': 16}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 10, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 11, 'v': 12}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 17, 'v': 23}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}], 'source_file': 'belgium_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0024.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0024.png', 'edge_connectivity': 1}","[2, 5, 7, 8, 11, 14, 16, 19, 22]",9.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'A'}, {'u': 'F', 'v': 'A'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'H', 'v': 'P'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'J', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'K', 'v': 'L'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'Q', 'v': 'W'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'W'}]}","['B', 'E', 'G', 'H', 'K', 'N', 'P', 'S', 'V']",25,csv,names | |
| MDS,MDS,"Someone in charge of staffing has to decide where to post on-call doctors across the wards tonight. Each posted doctor handles their own ward and can support neighboring wards, so the aim is to post as few doctors as possible while ensuring every ward is either the one with a doctor or sits next to one. Compare plans by looking at how many doctors are assigned — the lower that number, the better — but never at the cost of leaving a ward without coverage. Assigning multiple doctors to cover the same ward is unnecessary; cover every ward exactly by being next to or on a staffed ward. The specific map and numbers are listed below. | |
| There are 24 wards in total and 23 adjacencies. | |
| | ward_a_id | ward_b_id | | |
| |---|---| | |
| | 10 | 11 | | |
| | 10 | 17 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 16 | 8 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 3 | | |
| | 0 | 1 | | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 3 | 23 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 20 | 21 | | |
| | 21 | 22 | | |
| | 22 | 23 | | |
| | 9 | 8 | | |
| | 7 | 8 | | |
| When you're ready, just drop your plan into this little JSON shape so it's easy to check: | |
| { | |
| ""solution"": [""ward_id"", ""ward_id"", ...] | |
| } | |
| Pretty simple: ""solution"" should be a list of the ward identifiers where you'd post doctors. Each entry is the exact ward ID from the map (the ""... "" just means you can list as many wards as needed). This is just a sketch of the expected shape — not the final staffing plan. | |
| Please be sure to use the identifiers exactly as they appear in the instance input — don't rename or invent labels. For example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 11, 'v': 12}, {'u': 11, 'v': 18}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 9}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 4}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 4, 'v': 24}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 10, 'v': 9}, {'u': 8, 'v': 9}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0025.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0025.png', 'edge_connectivity': 1}","[2, 4, 6, 9, 12, 15, 18, 22]",8.0,"{'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 10, 'v': 11}, {'u': 10, 'v': 17}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 8}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 3}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 3, 'v': 23}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 9, 'v': 8}, {'u': 7, 'v': 8}]}","[1, 3, 5, 8, 11, 14, 17, 21]",26,markdown_table,0 | |
| MDS,MDS,"Many people imagine a delivery planner staring at a map and deciding which spots should be depots so that every drop point is either itself a depot or immediately beside one, but with as few depots as possible. The decision is which drop points to convert into depots; the better decision uses fewer depots while still reaching every drop point. To check whether a setup works, count the depots chosen and make sure every drop point ends up covered by being a depot or adjacent to one — nothing can be omitted and duplicates don’t change anything. The precise map follows below. | |
| There are 21 drop points and 21 adjacency pairs on the map. | |
| Drop point 7 is adjacent to drop point 8. | |
| Drop point 8 is adjacent to drop point 9. | |
| Drop point 9 is adjacent to drop point 2. | |
| Drop point 1 is adjacent to drop point 3. | |
| Drop point 2 is adjacent to drop point 3. | |
| Drop point 2 is adjacent to drop point 4. | |
| Drop point 2 is adjacent to drop point 11. | |
| Drop point 2 is adjacent to drop point 20. | |
| Drop point 3 is adjacent to drop point 16. | |
| Drop point 4 is adjacent to drop point 5. | |
| Drop point 5 is adjacent to drop point 6. | |
| Drop point 10 is adjacent to drop point 11. | |
| Drop point 13 is adjacent to drop point 14. | |
| Drop point 14 is adjacent to drop point 16. | |
| Drop point 14 is adjacent to drop point 17. | |
| Drop point 14 is adjacent to drop point 19. | |
| Drop point 15 is adjacent to drop point 16. | |
| Drop point 17 is adjacent to drop point 18. | |
| Drop point 19 is adjacent to drop point 20. | |
| Drop point 20 is adjacent to drop point 21. | |
| Drop point 12 is adjacent to drop point 11. | |
| This map of 21 drop points and 21 adjacency pairs is provided to evaluate depot selections. | |
| When you send your answer back, just use this simple JSON shape so I can read it easily. | |
| { | |
| ""solution"": [""depot_id"", ""depot_id"", ...] | |
| } | |
| Think of ""solution"" as the list of drop points you decided to turn into depots — each entry is the identifier for a location you picked. This block is just a sketch of the shape I expect, not the actual answer. | |
| Please use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 21, 'edges': [{'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 2}, {'u': 1, 'v': 3}, {'u': 2, 'v': 3}, {'u': 2, 'v': 4}, {'u': 2, 'v': 11}, {'u': 2, 'v': 20}, {'u': 3, 'v': 16}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 10, 'v': 11}, {'u': 13, 'v': 14}, {'u': 14, 'v': 16}, {'u': 14, 'v': 17}, {'u': 14, 'v': 19}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 12, 'v': 11}], 'source_file': 'belgium_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0026.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0026.png', 'edge_connectivity': 1}","[3, 5, 8, 11, 14, 16, 17, 20]",8.0,"{'num_nodes': 21, 'num_edges': 21, 'edges': [{'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 2}, {'u': 1, 'v': 3}, {'u': 2, 'v': 3}, {'u': 2, 'v': 4}, {'u': 2, 'v': 11}, {'u': 2, 'v': 20}, {'u': 3, 'v': 16}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 10, 'v': 11}, {'u': 13, 'v': 14}, {'u': 14, 'v': 16}, {'u': 14, 'v': 17}, {'u': 14, 'v': 19}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 12, 'v': 11}]}","[3, 5, 8, 11, 14, 16, 17, 20]",27,nl,1 | |
| MDS,MDS,"Out in the field the operations crew needs a simple rule: pick a compact set of base stations to power so every antenna site either is powered itself or sits right next to a powered site. Nothing can be left uncovered, and there’s no benefit to powering extra nearby stations unless required. The deciding factor is the number of powered stations — the plan with the lowest count is preferable; you compute that by tallying the active sites. Concrete details are shown below. | |
| There are 20 sites in total and 19 direct links. | |
| | site_endpoint_u | site_endpoint_v | | |
| |---|---| | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 20 | 11 | | |
| | 13 | 10 | | |
| | 13 | 14 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 8 | 19 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| And when you send the plan back, just use this tiny JSON shape so it's easy to parse: | |
| { | |
| ""solution"": [""site_id"", ""site_id"", ...] | |
| } | |
| Here ""solution"" is simply the list of base stations you'll power — one site ID per powered station. It's just a sketch of the shape I expect, not the actual answer. | |
| Please use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 20, 'v': 11}, {'u': 13, 'v': 10}, {'u': 13, 'v': 14}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 8, 'v': 19}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}], 'source_file': 'belgium_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0027.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0027.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 13, 16, 19]",7.0,"{'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 20, 'v': 11}, {'u': 13, 'v': 10}, {'u': 13, 'v': 14}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 8, 'v': 19}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}]}","[2, 5, 8, 11, 13, 16, 19]",28,markdown_table,1 | |
| MDS,MDS,"Someone on the conservation team is trying to cover an entire chain of habitats with camera traps, but they want the fewest traps that still leave no habitat without coverage — meaning every habitat either has a trap or is next to one. A better setup uses fewer traps, and that can be checked by counting the selected trap sites and verifying each habitat is either hosting a trap or adjacent to one. Nothing should be left uncovered, and placing multiple traps on the exact same habitat is pointless. The specific map and data are listed below. | |
| There are 20 num habitats in total and 19 num bordering pairs. | |
| | habitat_u | habitat_v | | |
| |---|---| | |
| | 4 | 1 | | |
| | 4 | 5 | | |
| | 4 | 17 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 18 | 19 | | |
| | 19 | 9 | | |
| | 20 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| Also, please return your chosen sites in this relaxed JSON shape so it's easy to check programmatically: | |
| { | |
| ""solution"": [""habitat_id"", ""habitat_id"", ...] | |
| } | |
| Here ""solution"" is just the list of habitat identifiers where you'd place camera traps — one entry per habitat. Think of it like a simple form: put each habitat's exact ID in the array. This is only a sketch of the shape I need, not the actual final selection. | |
| Please make sure to use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 4, 'v': 1}, {'u': 4, 'v': 5}, {'u': 4, 'v': 17}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 18, 'v': 19}, {'u': 19, 'v': 9}, {'u': 20, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0028.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0028.png', 'edge_connectivity': 1}","[2, 4, 7, 9, 12, 15, 19]",7.0,"{'num_nodes': 20, 'num_edges': 19, 'edges': [{'u': 4, 'v': 1}, {'u': 4, 'v': 5}, {'u': 4, 'v': 17}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 18, 'v': 19}, {'u': 19, 'v': 9}, {'u': 20, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}]}","[2, 4, 7, 9, 12, 15, 19]",29,markdown_table,1 | |
| MDS,MDS,"There’s a building that needs its wall extinguishers installed, and the challenge is choosing which rooms get them so no office is left unprotected: each office must either have an extinguisher on its wall or be adjacent to an office that does. A good setup uses the smallest number of extinguishers possible — the score is simply the number of units put up — and nothing can be skipped or double-counted. The concrete room map and details are shown below. | |
| There are 23 offices in total and 22 adjacency pairs. | |
| | office_a_id | office_b_id | | |
| |---|---| | |
| | 0 | 1 | | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 20 | | |
| | 20 | 21 | | |
| | 21 | 22 | | |
| I'll keep the answer ready in a simple JSON layout so it's easy to paste into whatever tool you're using. Just fill in the room IDs for where the extinguishers go. | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| ""solution"" is just the list of room IDs where we'll put extinguishers — one entry per room. Think of it like a checklist: list each room exactly as shown in the building map. This JSON is only a sketch of the shape I expect, not the final filled-in list. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}], 'source_file': 'italy_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0029.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0029.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 13, 16, 19, 22]",8.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 0, 'v': 1}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}]}","[1, 4, 7, 10, 12, 15, 18, 21]",30,markdown_table,0 | |
| MDS,MDS,"On a quiet night the curator mulls over where to place the overnight guards so that every exhibit room either has someone inside it or is connected by a doorway to a guarded room. The decision is about which rooms to occupy; a better layout uses as few guards as possible while still leaving zero rooms unobserved. The simplest way to pick between layouts is to count the guards — the plan with the smallest count that still reaches every room is preferred — and to ensure nothing is left unwatched and guards aren’t redundantly clustered. The detailed map and door links are shown below. | |
| # total_exhibit_rooms=20 | |
| # total_doorways=21 | |
| room_a,room_b | |
| 10,11 | |
| 11,0 | |
| 7,1 | |
| 7,8 | |
| 7,16 | |
| 8,9 | |
| 8,12 | |
| 9,19 | |
| 0,1 | |
| 0,2 | |
| 1,3 | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 12,13 | |
| 13,14 | |
| 13,18 | |
| 13,19 | |
| 14,15 | |
| 16,17 | |
| 17,18 | |
| Oh, and when you send back the guard plan, please use this simple JSON shape so it's easy to read by both people and the system: | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| ""solution"" should be a list of the room identifiers where you'll place the overnight guards. The placeholders show the format — replace each ""room_id"" with the actual room label from the map. This is just a sketch of the expected shape, not the actual answer. | |
| Please use the identifiers exactly as they appear in the instance input — do not rename them or make up new labels. For example: Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 21, 'edges': [{'u': 11, 'v': 12}, {'u': 12, 'v': 1}, {'u': 8, 'v': 2}, {'u': 8, 'v': 9}, {'u': 8, 'v': 17}, {'u': 9, 'v': 10}, {'u': 9, 'v': 13}, {'u': 10, 'v': 20}, {'u': 1, 'v': 2}, {'u': 1, 'v': 3}, {'u': 2, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 14, 'v': 19}, {'u': 14, 'v': 20}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}], 'source_file': 'netherlands_osm.mtx', 'density': 0.11052631578947368, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0030.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0030.png', 'edge_connectivity': 1}","[1, 2, 6, 10, 12, 14, 15, 18]",8.0,"{'num_nodes': 20, 'num_edges': 21, 'edges': [{'u': 10, 'v': 11}, {'u': 11, 'v': 0}, {'u': 7, 'v': 1}, {'u': 7, 'v': 8}, {'u': 7, 'v': 16}, {'u': 8, 'v': 9}, {'u': 8, 'v': 12}, {'u': 9, 'v': 19}, {'u': 0, 'v': 1}, {'u': 0, 'v': 2}, {'u': 1, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 13, 'v': 18}, {'u': 13, 'v': 19}, {'u': 14, 'v': 15}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}]}","[0, 1, 5, 9, 11, 13, 14, 17]",31,csv,0 | |
| MDS,MDS,"We’ve got a cluster of gates and a tight crew budget, so the task is to station the fewest possible ground-crew posts so every gate either has someone there or is right next door to one. The decision is which gates get the posts; to pick the best setup, compare how many posts each layout needs and pick the layout with the smallest total that still keeps every gate covered. Every gate must be covered, and duplicate or pointless posts that don’t extend coverage should be avoided. The specific layout details are shown below. | |
| { | |
| ""total_gates"": 25, | |
| ""total_gate_adjacencies"": 24, | |
| ""edges"": [ | |
| { | |
| ""gate_a_id"": ""V"", | |
| ""gate_b_id"": ""F"" | |
| }, | |
| { | |
| ""gate_a_id"": ""V"", | |
| ""gate_b_id"": ""W"" | |
| }, | |
| { | |
| ""gate_a_id"": ""W"", | |
| ""gate_b_id"": ""X"" | |
| }, | |
| { | |
| ""gate_a_id"": ""X"", | |
| ""gate_b_id"": ""Y"" | |
| }, | |
| { | |
| ""gate_a_id"": ""U"", | |
| ""gate_b_id"": ""P"" | |
| }, | |
| { | |
| ""gate_a_id"": ""A"", | |
| ""gate_b_id"": ""B"" | |
| }, | |
| { | |
| ""gate_a_id"": ""B"", | |
| ""gate_b_id"": ""C"" | |
| }, | |
| { | |
| ""gate_a_id"": ""C"", | |
| ""gate_b_id"": ""D"" | |
| }, | |
| { | |
| ""gate_a_id"": ""D"", | |
| ""gate_b_id"": ""E"" | |
| }, | |
| { | |
| ""gate_a_id"": ""E"", | |
| ""gate_b_id"": ""F"" | |
| }, | |
| { | |
| ""gate_a_id"": ""F"", | |
| ""gate_b_id"": ""G"" | |
| }, | |
| { | |
| ""gate_a_id"": ""G"", | |
| ""gate_b_id"": ""H"" | |
| }, | |
| { | |
| ""gate_a_id"": ""H"", | |
| ""gate_b_id"": ""I"" | |
| }, | |
| { | |
| ""gate_a_id"": ""I"", | |
| ""gate_b_id"": ""J"" | |
| }, | |
| { | |
| ""gate_a_id"": ""J"", | |
| ""gate_b_id"": ""K"" | |
| }, | |
| { | |
| ""gate_a_id"": ""K"", | |
| ""gate_b_id"": ""L"" | |
| }, | |
| { | |
| ""gate_a_id"": ""L"", | |
| ""gate_b_id"": ""M"" | |
| }, | |
| { | |
| ""gate_a_id"": ""M"", | |
| ""gate_b_id"": ""N"" | |
| }, | |
| { | |
| ""gate_a_id"": ""N"", | |
| ""gate_b_id"": ""O"" | |
| }, | |
| { | |
| ""gate_a_id"": ""O"", | |
| ""gate_b_id"": ""P"" | |
| }, | |
| { | |
| ""gate_a_id"": ""P"", | |
| ""gate_b_id"": ""Q"" | |
| }, | |
| { | |
| ""gate_a_id"": ""Q"", | |
| ""gate_b_id"": ""R"" | |
| }, | |
| { | |
| ""gate_a_id"": ""R"", | |
| ""gate_b_id"": ""S"" | |
| }, | |
| { | |
| ""gate_a_id"": ""S"", | |
| ""gate_b_id"": ""T"" | |
| } | |
| ] | |
| } | |
| Also, when you hand in the final gate picks, keep it simple and use this JSON layout so whoever reads it knows exactly where the posts go: | |
| { | |
| ""solution"": [""vertex_id"", ""vertex_id"", ...] | |
| } | |
| ""solution"" is just the list of gates where you put crew posts — think of it like ticking off the gate labels you chose. This JSON is only a sketch of the shape I want, not the actual answer itself. | |
| Please make sure to use the exact gate identifiers as they appear in the instance input — don't rename them or invent new labels. Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 22, 'v': 6}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 24, 'v': 25}, {'u': 21, 'v': 16}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}], 'source_file': 'great-britain_osm.mtx', 'density': 0.08, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0031.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0031.png', 'edge_connectivity': 1}","[2, 5, 6, 9, 10, 13, 16, 19, 24]",9.0,"{'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 'V', 'v': 'F'}, {'u': 'V', 'v': 'W'}, {'u': 'W', 'v': 'X'}, {'u': 'X', 'v': 'Y'}, {'u': 'U', 'v': 'P'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}]}","['B', 'E', 'F', 'I', 'J', 'M', 'P', 'S', 'X']",32,json,names | |
| MDS,MDS,"On a busy weekend the ops team has to decide which rides get people posted so that every attraction either has staff or is next to one that does. The clear goal is to keep the total number of staffed attractions as low as possible — evaluate each proposal by counting staffed rides and pick the smallest count. Every ride must be covered under those rules, and repeats (staffing the same ride more than once) aren’t part of a good plan. The concrete details will be shown below. | |
| There are 23 attractions and 22 adjacency pairs to consider. | |
| Ride B is adjacent to ride A; staffing either covers the other. | |
| Ride B is adjacent to ride C; staffing either covers the other. | |
| Ride B is adjacent to ride S; staffing either covers the other. | |
| Ride C is adjacent to ride D; staffing either covers the other. | |
| Ride C is adjacent to ride W; staffing either covers the other. | |
| Ride D is adjacent to ride E; staffing either covers the other. | |
| Ride E is adjacent to ride F; staffing either covers the other. | |
| Ride F is adjacent to ride G; staffing either covers the other. | |
| Ride G is adjacent to ride H; staffing either covers the other. | |
| Ride H is adjacent to ride I; staffing either covers the other. | |
| Ride I is adjacent to ride J; staffing either covers the other. | |
| Ride J is adjacent to ride K; staffing either covers the other. | |
| Ride K is adjacent to ride L; staffing either covers the other. | |
| Ride L is adjacent to ride M; staffing either covers the other. | |
| Ride M is adjacent to ride N; staffing either covers the other. | |
| Ride N is adjacent to ride O; staffing either covers the other. | |
| Ride O is adjacent to ride P; staffing either covers the other. | |
| Ride P is adjacent to ride Q; staffing either covers the other. | |
| Ride A is adjacent to ride R; staffing either covers the other. | |
| Ride T is adjacent to ride U; staffing either covers the other. | |
| Ride U is adjacent to ride V; staffing either covers the other. | |
| Ride V is adjacent to ride W; staffing either covers the other. | |
| The ops team will count staffed rides and choose the plan with the smallest total across the 23 attractions. | |
| Also, when you send back the staffing plan, please use this simple JSON layout so it's easy to read and check: | |
| { | |
| ""solution"": [""ride_id"", ""ride_id"", ...] | |
| } | |
| This ""solution"" array should list the rides you'll staff — one identifier per ride, no duplicates. Think of it like filling out a short form: put the exact ride IDs you pick into that list. The JSON above is just a sketch of the shape I expect, not the actual answer itself. | |
| Please use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 2, 'v': 1}, {'u': 2, 'v': 3}, {'u': 2, 'v': 19}, {'u': 3, 'v': 4}, {'u': 3, 'v': 23}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 1, 'v': 18}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0032.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0032.png', 'edge_connectivity': 1}","[1, 2, 3, 6, 9, 10, 13, 16, 21]",9.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 'B', 'v': 'A'}, {'u': 'B', 'v': 'C'}, {'u': 'B', 'v': 'S'}, {'u': 'C', 'v': 'D'}, {'u': 'C', 'v': 'W'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'A', 'v': 'R'}, {'u': 'T', 'v': 'U'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'W'}]}","['A', 'B', 'C', 'F', 'I', 'J', 'M', 'P', 'U']",33,nl,names | |
| MDS,MDS,"In the control room the assignment is to select a handful of substations to energize so that every substation is either powered or directly connected to a powered one. The decision is which locations to activate; the better the selection, the fewer substations need to be energized while still reaching every substation. Evaluate options by counting how many are turned on — the plan with the lowest count that still covers everything is preferred — and ensure that every substation is covered (powered itself or next to a powered one), without leaving gaps. The precise layout is shown below. | |
| { | |
| ""total_substations"": 19, | |
| ""total_direct_links"": 19, | |
| ""edges"": [ | |
| { | |
| ""link_endpoint_a"": ""E"", | |
| ""link_endpoint_b"": ""A"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""E"", | |
| ""link_endpoint_b"": ""F"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""F"", | |
| ""link_endpoint_b"": ""G"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""G"", | |
| ""link_endpoint_b"": ""H"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""G"", | |
| ""link_endpoint_b"": ""K"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""H"", | |
| ""link_endpoint_b"": ""I"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""I"", | |
| ""link_endpoint_b"": ""J"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""J"", | |
| ""link_endpoint_b"": ""B"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""A"", | |
| ""link_endpoint_b"": ""B"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""S"", | |
| ""link_endpoint_b"": ""D"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""K"", | |
| ""link_endpoint_b"": ""L"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""L"", | |
| ""link_endpoint_b"": ""M"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""M"", | |
| ""link_endpoint_b"": ""N"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""N"", | |
| ""link_endpoint_b"": ""O"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""O"", | |
| ""link_endpoint_b"": ""P"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""P"", | |
| ""link_endpoint_b"": ""Q"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""Q"", | |
| ""link_endpoint_b"": ""R"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""R"", | |
| ""link_endpoint_b"": ""D"" | |
| }, | |
| { | |
| ""link_endpoint_a"": ""C"", | |
| ""link_endpoint_b"": ""D"" | |
| } | |
| ] | |
| } | |
| When you send back your pick, please use this simple JSON shape so I can read it automatically: | |
| { | |
| ""solution"": [""substation_id"", ""substation_id"", ...] | |
| } | |
| ""solution"" is just the list of substations you'll energize. Replace each ""substation_id"" with the exact ID from the instance (it's just a placeholder here), and put all chosen IDs in that array. Think of this as a little form template — it's the shape I need, not the final choices. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| For example: Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 19, 'num_edges': 19, 'edges': [{'u': 5, 'v': 1}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 11}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 2}, {'u': 1, 'v': 2}, {'u': 19, 'v': 4}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 4}, {'u': 3, 'v': 4}], 'source_file': 'belgium_osm.mtx', 'density': 0.1111111111111111, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0033.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0033.png', 'edge_connectivity': 1}","[1, 4, 7, 10, 13, 16]",6.0,"{'num_nodes': 19, 'num_edges': 19, 'edges': [{'u': 'E', 'v': 'A'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'G', 'v': 'K'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'B'}, {'u': 'A', 'v': 'B'}, {'u': 'S', 'v': 'D'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'D'}, {'u': 'C', 'v': 'D'}]}","['A', 'D', 'G', 'J', 'M', 'P']",34,json,names | |
| MDS,MDS,"My friend is coordinating club hosts and needs to pick a compact crew of hosts so every group either hosts someone or is connected to a group that does. The better the crew, the fewer people on it — you can compare options by counting the hosts — and it’s essential that every group is covered and nobody is double-booked. The full list of groups and how they link up is below. | |
| There are 24 groups in total and 23 connections. | |
| | group_a | group_b | | |
| |---|---| | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 7 | 20 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 2 | | |
| | 21 | 2 | | |
| | 21 | 22 | | |
| | 22 | 23 | | |
| | 15 | 1 | | |
| | 15 | 16 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 20 | | |
| | 0 | 1 | | |
| | 1 | 2 | | |
| Also, when you send the final pick, please use this simple JSON layout so it's easy to parse: | |
| { | |
| ""solution"": [""host_id"", ""host_id"", ...] | |
| } | |
| This just means ""solution"" is a list of the chosen hosts (your compact crew). Each entry should be the exact identifier for a group from the instance — think of it like filling in names on a sign-up sheet. The JSON above is only a sketch of the expected shape, not the actual answer. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 8, 'v': 21}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 3}, {'u': 22, 'v': 3}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 16, 'v': 2}, {'u': 16, 'v': 17}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}], 'source_file': 'belgium_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0034.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0034.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 14, 16, 19, 23]",8.0,"{'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 20}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 2}, {'u': 21, 'v': 2}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 15, 'v': 1}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}]}","[1, 4, 7, 10, 13, 15, 18, 22]",35,markdown_table,0 | |
| MDS,MDS,"Someone at the box office sketched a plan to put preview screens in some theaters so that every room either contains a screen or touches a room that does. The idea is to pick the arrangement that uses the fewest screens possible — compare candidate layouts by the total number of screens and pick the smallest — and make sure every theater is covered while avoiding needless duplicates. The detailed seating/layout info follows below. | |
| { | |
| ""total_theaters"": 25, | |
| ""total_shared_walls"": 25, | |
| ""edges"": [ | |
| { | |
| ""theater_a_id"": ""J"", | |
| ""theater_b_id"": ""K"" | |
| }, | |
| { | |
| ""theater_a_id"": ""A"", | |
| ""theater_b_id"": ""B"" | |
| }, | |
| { | |
| ""theater_a_id"": ""B"", | |
| ""theater_b_id"": ""C"" | |
| }, | |
| { | |
| ""theater_a_id"": ""C"", | |
| ""theater_b_id"": ""D"" | |
| }, | |
| { | |
| ""theater_a_id"": ""D"", | |
| ""theater_b_id"": ""E"" | |
| }, | |
| { | |
| ""theater_a_id"": ""E"", | |
| ""theater_b_id"": ""F"" | |
| }, | |
| { | |
| ""theater_a_id"": ""E"", | |
| ""theater_b_id"": ""P"" | |
| }, | |
| { | |
| ""theater_a_id"": ""F"", | |
| ""theater_b_id"": ""G"" | |
| }, | |
| { | |
| ""theater_a_id"": ""G"", | |
| ""theater_b_id"": ""H"" | |
| }, | |
| { | |
| ""theater_a_id"": ""H"", | |
| ""theater_b_id"": ""I"" | |
| }, | |
| { | |
| ""theater_a_id"": ""P"", | |
| ""theater_b_id"": ""Q"" | |
| }, | |
| { | |
| ""theater_a_id"": ""P"", | |
| ""theater_b_id"": ""X"" | |
| }, | |
| { | |
| ""theater_a_id"": ""Q"", | |
| ""theater_b_id"": ""R"" | |
| }, | |
| { | |
| ""theater_a_id"": ""R"", | |
| ""theater_b_id"": ""S"" | |
| }, | |
| { | |
| ""theater_a_id"": ""S"", | |
| ""theater_b_id"": ""T"" | |
| }, | |
| { | |
| ""theater_a_id"": ""T"", | |
| ""theater_b_id"": ""U"" | |
| }, | |
| { | |
| ""theater_a_id"": ""V"", | |
| ""theater_b_id"": ""O"" | |
| }, | |
| { | |
| ""theater_a_id"": ""V"", | |
| ""theater_b_id"": ""W"" | |
| }, | |
| { | |
| ""theater_a_id"": ""W"", | |
| ""theater_b_id"": ""M"" | |
| }, | |
| { | |
| ""theater_a_id"": ""K"", | |
| ""theater_b_id"": ""L"" | |
| }, | |
| { | |
| ""theater_a_id"": ""L"", | |
| ""theater_b_id"": ""M"" | |
| }, | |
| { | |
| ""theater_a_id"": ""L"", | |
| ""theater_b_id"": ""Y"" | |
| }, | |
| { | |
| ""theater_a_id"": ""X"", | |
| ""theater_b_id"": ""Y"" | |
| }, | |
| { | |
| ""theater_a_id"": ""M"", | |
| ""theater_b_id"": ""N"" | |
| }, | |
| { | |
| ""theater_a_id"": ""N"", | |
| ""theater_b_id"": ""O"" | |
| } | |
| ] | |
| } | |
| If you want to send back the final pick, just drop it into a tiny JSON snippet like this so it's easy to read and parse: | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| Think of that as a simple form: ""solution"" is the list of room IDs where we put the preview screens — one entry per room. This is just the shape I expect, not the actual answer itself. | |
| Please make sure you use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 10, 'v': 11}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 5, 'v': 16}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 16, 'v': 17}, {'u': 16, 'v': 24}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 22, 'v': 15}, {'u': 22, 'v': 23}, {'u': 23, 'v': 13}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 12, 'v': 25}, {'u': 24, 'v': 25}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}], 'source_file': 'italy_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0035.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0035.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 13, 15, 17, 20, 24]",9.0,"{'num_nodes': 25, 'num_edges': 25, 'edges': [{'u': 'J', 'v': 'K'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'E', 'v': 'P'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'P', 'v': 'Q'}, {'u': 'P', 'v': 'X'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'U'}, {'u': 'V', 'v': 'O'}, {'u': 'V', 'v': 'W'}, {'u': 'W', 'v': 'M'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'L', 'v': 'Y'}, {'u': 'X', 'v': 'Y'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}]}","['B', 'E', 'H', 'K', 'M', 'O', 'Q', 'T', 'X']",36,json,names | |
| MDS,MDS,"Someone on the operations crew suggested spreading a few repair kiosks around the stations so every dock has access within one hop — either it has the kiosk or its neighbor does. The best plan is the one that uses the least kiosks; evaluating plans is just a matter of counting kiosks and picking the smallest count. Every dock must be covered under that rule, and kiosks are assigned to individual docks only. The concrete instance is shown below. | |
| # total_docks=23 | |
| # total_adjacent_pairs=22 | |
| dock_u,dock_v | |
| 7,1 | |
| 7,8 | |
| 8,9 | |
| 9,10 | |
| 9,15 | |
| 10,11 | |
| 11,12 | |
| 16,17 | |
| 17,18 | |
| 18,19 | |
| 19,20 | |
| 20,21 | |
| 21,22 | |
| 22,23 | |
| 23,1 | |
| 13,14 | |
| 1,2 | |
| 2,3 | |
| 3,4 | |
| 4,5 | |
| 15,14 | |
| 6,5 | |
| Also, when you give the final plan, just stick to this simple JSON shape so it's easy to check: | |
| { | |
| ""solution"": [""dock_id"", ""dock_id"", ...] | |
| } | |
| Here ""solution"" is just a list of the docks where we'll put kiosks — one identifier per kiosk. Think of it like filling out a short form: list the exact dock IDs you choose, and that’s it. This block is only a sketch of the expected shape, not the actual answer. | |
| Please use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. For example: Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 7, 'v': 1}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 9, 'v': 15}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 1}, {'u': 13, 'v': 14}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 15, 'v': 14}, {'u': 6, 'v': 5}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0036.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0036.png', 'edge_connectivity': 1}","[2, 5, 8, 11, 14, 17, 20, 22]",8.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 7, 'v': 1}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 9, 'v': 15}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 1}, {'u': 13, 'v': 14}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 15, 'v': 14}, {'u': 6, 'v': 5}]}","[2, 5, 8, 11, 14, 17, 20, 22]",37,csv,1 | |
| MDS,MDS,"I manage a cluster of neighborhood library branches and I’ve got to decide which ones actually need a librarian posted so that every branch either has someone on-site or is right next door to a branch that does. The better plan is the one that uses the fewest librarians overall — just tally how many librarians are placed, and the smallest tally that still leaves no branch unserved wins. Every branch must be covered (either staffed or beside a staffed branch) and avoid putting extra, unnecessary librarians where they don’t help. The exact map of branches and who’s next to whom is listed below. | |
| There are 22 branches in total and 26 adjacent branch pairs. | |
| | branch_a_id | branch_b_id | | |
| |---|---| | |
| | F | G | | |
| | F | L | | |
| | F | V | | |
| | G | C | | |
| | G | Q | | |
| | G | S | | |
| | U | T | | |
| | U | V | | |
| | V | H | | |
| | V | Q | | |
| | A | H | | |
| | M | N | | |
| | M | T | | |
| | N | O | | |
| | O | P | | |
| | P | H | | |
| | B | C | | |
| | B | D | | |
| | B | L | | |
| | R | S | | |
| | D | E | | |
| | E | I | | |
| | E | T | | |
| | I | J | | |
| | J | K | | |
| | K | L | | |
| Also, when you send back the final list, please use this simple JSON layout so it's easy to read and plug into the system: | |
| { | |
| ""solution"": [""branch_id"", ""branch_id"", ...] | |
| } | |
| Think of that as a tiny form: ""solution"" is the list of branches where you'll place librarians, and each ""branch_id"" is a placeholder for an actual branch label from the instance. This is just a sketch of the shape I want — when you submit the real answer, replace those placeholders with the exact identifiers from the input. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 22, 'num_edges': 26, 'edges': [{'u': 6, 'v': 7}, {'u': 6, 'v': 12}, {'u': 6, 'v': 22}, {'u': 7, 'v': 3}, {'u': 7, 'v': 17}, {'u': 7, 'v': 19}, {'u': 21, 'v': 20}, {'u': 21, 'v': 22}, {'u': 22, 'v': 8}, {'u': 22, 'v': 17}, {'u': 1, 'v': 8}, {'u': 13, 'v': 14}, {'u': 13, 'v': 20}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 8}, {'u': 2, 'v': 3}, {'u': 2, 'v': 4}, {'u': 2, 'v': 12}, {'u': 18, 'v': 19}, {'u': 4, 'v': 5}, {'u': 5, 'v': 9}, {'u': 5, 'v': 20}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.11255411255411256, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0037.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0037.png', 'edge_connectivity': 1}","[2, 8, 10, 14, 19, 20, 22]",7.0,"{'num_nodes': 22, 'num_edges': 26, 'edges': [{'u': 'F', 'v': 'G'}, {'u': 'F', 'v': 'L'}, {'u': 'F', 'v': 'V'}, {'u': 'G', 'v': 'C'}, {'u': 'G', 'v': 'Q'}, {'u': 'G', 'v': 'S'}, {'u': 'U', 'v': 'T'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'H'}, {'u': 'V', 'v': 'Q'}, {'u': 'A', 'v': 'H'}, {'u': 'M', 'v': 'N'}, {'u': 'M', 'v': 'T'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'H'}, {'u': 'B', 'v': 'C'}, {'u': 'B', 'v': 'D'}, {'u': 'B', 'v': 'L'}, {'u': 'R', 'v': 'S'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'I'}, {'u': 'E', 'v': 'T'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}]}","['B', 'H', 'J', 'N', 'S', 'T', 'V']",38,markdown_table,names | |
| MDS,MDS,"On a busy weekend the coordinator wants to station attendants in just enough places that every parking bay either has someone there or is adjacent to a bay that does. The decision is where to stand people so that there aren’t unnecessary duplicates but also no unmonitored areas. The way to tell which arrangement is best is to count how many attendants are placed — smaller counts are preferable — while making sure every bay is covered either directly or by a neighbor. The exact lot plan is shown below. | |
| There are 24 parking bays in total and 23 abutting pairs. | |
| | bay_endpoint_a | bay_endpoint_b | | |
| |---|---| | |
| | 14 | 15 | | |
| | 15 | 7 | | |
| | 16 | 7 | | |
| | 0 | 1 | | |
| | 0 | 13 | | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 20 | | |
| | 20 | 12 | | |
| | 21 | 12 | | |
| | 21 | 22 | | |
| | 22 | 23 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| Also, when you send the placement back, just stick to this simple JSON shape so it's easy to read and check: | |
| { | |
| ""solution"": [""bay_id"", ""bay_id"", ...] | |
| } | |
| The ""solution"" array is where you list the bay identifiers where attendants will stand — think of each placeholder as a spot name on the lot plan. This block is only a sketch of the shape I need, not the actual final answer. | |
| Please make sure to use the exact identifiers from the instance input — don't rename them or create new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as ""1"" or ""23"", single capital letters like ""A"" or ""B"", or a capital letter followed by digits like ""A1"" or ""X7"".""","{'problem_type': 'MDS', 'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 15, 'v': 16}, {'u': 16, 'v': 8}, {'u': 17, 'v': 8}, {'u': 1, 'v': 2}, {'u': 1, 'v': 14}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 13}, {'u': 22, 'v': 13}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}], 'source_file': 'belgium_osm.mtx', 'density': 0.08333333333333333, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0038.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0038.png', 'edge_connectivity': 1}","[2, 5, 8, 10, 13, 16, 19, 23]",8.0,"{'num_nodes': 24, 'num_edges': 23, 'edges': [{'u': 14, 'v': 15}, {'u': 15, 'v': 7}, {'u': 16, 'v': 7}, {'u': 0, 'v': 1}, {'u': 0, 'v': 13}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 12}, {'u': 21, 'v': 12}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}]}","[1, 4, 7, 9, 12, 15, 18, 22]",39,markdown_table,0 | |
| MDS,MDS,"A building manager needs to choose which corridors get surveillance so that every corridor is either equipped with a camera or directly beside one that is. What counts as a smarter choice is clear: use fewer cameras — tally the cameras to judge — while guaranteeing no corridor is left unwatched and no placement is counted more than once. The concrete layout and other details follow below. | |
| There are 20 corridors and 24 adjacencies in the layout: | |
| Corridor 5 is directly beside corridor 0. | |
| Corridor 5 is directly beside corridor 4. | |
| Corridor 5 is directly beside corridor 6. | |
| Corridor 6 is directly beside corridor 7. | |
| Corridor 6 is directly beside corridor 18. | |
| Corridor 7 is directly beside corridor 8. | |
| Corridor 8 is directly beside corridor 9. | |
| Corridor 9 is directly beside corridor 11. | |
| Corridor 9 is directly beside corridor 12. | |
| Corridor 10 is directly beside corridor 11. | |
| Corridor 12 is directly beside corridor 13. | |
| Corridor 12 is directly beside corridor 16. | |
| Corridor 13 is directly beside corridor 2. | |
| Corridor 13 is directly beside corridor 18. | |
| Corridor 14 is directly beside corridor 0. | |
| Corridor 14 is directly beside corridor 2. | |
| Corridor 14 is directly beside corridor 15. | |
| Corridor 15 is directly beside corridor 3. | |
| Corridor 15 is directly beside corridor 19. | |
| Corridor 16 is directly beside corridor 17. | |
| Corridor 17 is directly beside corridor 18. | |
| Corridor 19 is directly beside corridor 4. | |
| Corridor 0 is directly beside corridor 1. | |
| Corridor 1 is directly beside corridor 2. | |
| The manager will minimize cameras to cover all 20 corridors while ensuring no placement is counted more than once. | |
| Also, when you send back the actual selection, please use this simple JSON shape — just a quick form to fill out: | |
| { | |
| ""solution"": [""corridor_id"", ""corridor_id"", ...] | |
| } | |
| Pretty straightforward: ""solution"" is the list of corridor identifiers where you’d place cameras so every corridor is either watched or adjacent to a watched one. Think of it like ticking boxes on a short form — this block is just the shape I expect, not the real answer. | |
| Please make sure to use the exact identifiers from the instance input — do not rename them or invent new labels. Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 24, 'edges': [{'u': 6, 'v': 1}, {'u': 6, 'v': 5}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 7, 'v': 19}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 12}, {'u': 10, 'v': 13}, {'u': 11, 'v': 12}, {'u': 13, 'v': 14}, {'u': 13, 'v': 17}, {'u': 14, 'v': 3}, {'u': 14, 'v': 19}, {'u': 15, 'v': 1}, {'u': 15, 'v': 3}, {'u': 15, 'v': 16}, {'u': 16, 'v': 4}, {'u': 16, 'v': 20}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 20, 'v': 5}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}], 'source_file': 'italy_osm.mtx', 'density': 0.12631578947368421, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0039.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0039.png', 'edge_connectivity': 1}","[3, 6, 7, 8, 12, 16, 17]",7.0,"{'num_nodes': 20, 'num_edges': 24, 'edges': [{'u': 5, 'v': 0}, {'u': 5, 'v': 4}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 6, 'v': 18}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 11}, {'u': 9, 'v': 12}, {'u': 10, 'v': 11}, {'u': 12, 'v': 13}, {'u': 12, 'v': 16}, {'u': 13, 'v': 2}, {'u': 13, 'v': 18}, {'u': 14, 'v': 0}, {'u': 14, 'v': 2}, {'u': 14, 'v': 15}, {'u': 15, 'v': 3}, {'u': 15, 'v': 19}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 19, 'v': 4}, {'u': 0, 'v': 1}, {'u': 1, 'v': 2}]}","[2, 5, 6, 7, 11, 15, 16]",40,nl,0 | |
| MDS,MDS,"I live on a little block where some houses share fences and porches, and the question is which mailboxes to lock so every house is covered — either its own box is locked or one of its neighbors’ is. The aim is to lock as few mailboxes as possible: count the locked boxes and pick the plan with the smallest count that still leaves no house unprotected. Nothing should be skipped — every house must be protected by at least one locked mailbox, and locking the same box twice doesn’t help. The exact street map and mailbox list are shown below. | |
| There are 20 houses in total and 21 adjacent pairs. | |
| | house_id_one | house_id_two | | |
| |---|---| | |
| | S | N | | |
| | S | T | | |
| | C | B | | |
| | C | D | | |
| | D | E | | |
| | D | P | | |
| | E | F | | |
| | E | M | | |
| | F | G | | |
| | G | H | | |
| | H | L | | |
| | I | J | | |
| | J | K | | |
| | K | L | | |
| | K | M | | |
| | R | O | | |
| | A | B | | |
| | M | N | | |
| | N | O | | |
| | O | P | | |
| | P | Q | | |
| Oh, and to keep things tidy, please give the final plan in this simple JSON shape so it’s easy for me (or a program) to read: | |
| { | |
| ""solution"": [""mailbox_id"", ""mailbox_id"", ...] | |
| } | |
| Think of ""solution"" as the list of mailbox IDs you plan to lock — each item should be the exact ID of a house/mailbox from the street map. This JSON is just a sketch of the shape I expect, not the actual answer. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”."" | |
| Use the identifiers exactly as they appear in the instance input — no renaming and no new labels.","{'problem_type': 'MDS', 'num_nodes': 20, 'num_edges': 21, 'edges': [{'u': 19, 'v': 14}, {'u': 19, 'v': 20}, {'u': 3, 'v': 2}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 4, 'v': 16}, {'u': 5, 'v': 6}, {'u': 5, 'v': 13}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 12}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 11, 'v': 13}, {'u': 18, 'v': 15}, {'u': 1, 'v': 2}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}], 'source_file': 'great-britain_osm.mtx', 'density': 0.11052631578947368, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0040.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0040.png', 'edge_connectivity': 1}","[2, 5, 8, 10, 15, 16, 19]",7.0,"{'num_nodes': 20, 'num_edges': 21, 'edges': [{'u': 'S', 'v': 'N'}, {'u': 'S', 'v': 'T'}, {'u': 'C', 'v': 'B'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'D', 'v': 'P'}, {'u': 'E', 'v': 'F'}, {'u': 'E', 'v': 'M'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'L'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'K', 'v': 'M'}, {'u': 'R', 'v': 'O'}, {'u': 'A', 'v': 'B'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}]}","['B', 'E', 'H', 'J', 'O', 'P', 'S']",41,markdown_table,names | |
| MDS,MDS,"Recently the planning office asked for a lighting sketch: pick a handful of intersections to host streetlights so that every intersection is either one of those lit spots or directly next to one. What makes one sketch better than another is straightforward — fewer lights is better, and that’s measured by adding up how many lights are placed. Every junction must be covered; leaving a junction without a light or an adjacent light isn’t allowed, and putting extra lights that don’t cover new spots is just wasteful. The exact instance details are listed below. | |
| There are 23 intersections in total and 23 streets. | |
| | intersection_u | intersection_v | | |
| |---|---| | |
| | T | O | | |
| | J | F | | |
| | J | H | | |
| | J | N | | |
| | Q | F | | |
| | Q | K | | |
| | U | K | | |
| | F | G | | |
| | G | I | | |
| | G | S | | |
| | O | M | | |
| | O | P | | |
| | P | R | | |
| | V | A | | |
| | K | L | | |
| | L | M | | |
| | W | A | | |
| | I | B | | |
| | A | B | | |
| | B | C | | |
| | C | D | | |
| | D | E | | |
| | R | S | | |
| If you want the answer in a tidy, machine-friendly form, just use this simple JSON shape — nothing fancy, just a small list of the intersections you chose to light: | |
| { | |
| ""solution"": [""intersection_id"", ""intersection_id"", ...] | |
| } | |
| Think of this as a little form: ""solution"" holds an array of the intersections that will get lights. The placeholder entries above are just showing the shape — replace them with the actual intersection identifiers from the instance when you give the real answer. | |
| Please be sure to use the identifiers exactly as they appear in the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 23, 'edges': [{'u': 20, 'v': 15}, {'u': 10, 'v': 6}, {'u': 10, 'v': 8}, {'u': 10, 'v': 14}, {'u': 17, 'v': 6}, {'u': 17, 'v': 11}, {'u': 21, 'v': 11}, {'u': 6, 'v': 7}, {'u': 7, 'v': 9}, {'u': 7, 'v': 19}, {'u': 15, 'v': 13}, {'u': 15, 'v': 16}, {'u': 16, 'v': 18}, {'u': 22, 'v': 1}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 23, 'v': 1}, {'u': 9, 'v': 2}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 18, 'v': 19}], 'source_file': 'netherlands_osm.mtx', 'density': 0.09090909090909091, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0041.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0041.png', 'edge_connectivity': 1}","[1, 4, 7, 10, 11, 15, 19]",7.0,"{'num_nodes': 23, 'num_edges': 23, 'edges': [{'u': 'T', 'v': 'O'}, {'u': 'J', 'v': 'F'}, {'u': 'J', 'v': 'H'}, {'u': 'J', 'v': 'N'}, {'u': 'Q', 'v': 'F'}, {'u': 'Q', 'v': 'K'}, {'u': 'U', 'v': 'K'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'I'}, {'u': 'G', 'v': 'S'}, {'u': 'O', 'v': 'M'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'R'}, {'u': 'V', 'v': 'A'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'W', 'v': 'A'}, {'u': 'I', 'v': 'B'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'R', 'v': 'S'}]}","['A', 'D', 'G', 'J', 'K', 'O', 'S']",42,markdown_table,names | |
| MDS,MDS,"Many people on the floor have been wondering who the official points of contact should be, so HR needs to pick a small set of team leads such that everyone is either a lead themselves or works directly with a lead. Better plans are simply those that use fewer leads while still reaching every employee — for any proposed set, mark the staff it reaches (including the leads themselves), count how many leads are in that set, and choose the smallest count that still covers everyone. No one can be left off the list. The detailed team relationships are shown below. | |
| # total_employees=21 | |
| # total_working_pairs=21 | |
| employee_a,employee_b | |
| 11,8 | |
| 1,2 | |
| 1,5 | |
| 1,10 | |
| 2,3 | |
| 3,4 | |
| 5,6 | |
| 19,10 | |
| 19,20 | |
| 20,21 | |
| 12,13 | |
| 12,18 | |
| 13,14 | |
| 14,10 | |
| 14,15 | |
| 15,8 | |
| 15,16 | |
| 16,17 | |
| 17,18 | |
| 7,8 | |
| 8,9 | |
| Also, when you send back which people should be leads, a tiny bit of JSON like this makes it easy to read and reuse: | |
| { | |
| ""solution"": [""staff_id"", ""staff_id"", ...] | |
| } | |
| Pretty simple: ""solution"" is the list of staff IDs you pick as leads — each entry should be the exact identifier for a person from the instance (the person you want as a point of contact). Think of it like filling in a short form: replace the placeholders with the real IDs for the chosen leads. This is just the shape I expect, not the actual answer yet. | |
| All identifiers must be used exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 21, 'edges': [{'u': 11, 'v': 8}, {'u': 1, 'v': 2}, {'u': 1, 'v': 5}, {'u': 1, 'v': 10}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 5, 'v': 6}, {'u': 19, 'v': 10}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 12, 'v': 13}, {'u': 12, 'v': 18}, {'u': 13, 'v': 14}, {'u': 14, 'v': 10}, {'u': 14, 'v': 15}, {'u': 15, 'v': 8}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}], 'source_file': 'netherlands_osm.mtx', 'density': 0.1, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0042.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0042.png', 'edge_connectivity': 1}","[3, 5, 8, 14, 17, 18, 20]",7.0,"{'num_nodes': 21, 'num_edges': 21, 'edges': [{'u': 11, 'v': 8}, {'u': 1, 'v': 2}, {'u': 1, 'v': 5}, {'u': 1, 'v': 10}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 5, 'v': 6}, {'u': 19, 'v': 10}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 12, 'v': 13}, {'u': 12, 'v': 18}, {'u': 13, 'v': 14}, {'u': 14, 'v': 10}, {'u': 14, 'v': 15}, {'u': 15, 'v': 8}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}]}","[3, 5, 8, 14, 17, 18, 20]",43,csv,1 | |
| MDS,MDS,"I’m handling the regional health schedule and the trick is this: pick a handful of clinics to put a specialist in so that every village either has that specialist on site or sits next to a village that does. The better plan is simply the one with the fewest staffed clinics while still making sure no village is left without a nearby specialist. Figure out how many clinics each plan uses (just count the staffed clinics) and the plan with the smallest count that covers every village wins. Don’t leave any village uncovered and don’t count the same clinic twice — the map and exact village-to-clinic links are shown below. | |
| I see 21 villages and 20 bordering pairs on the map below. | |
| If I staff the clinic at I, it will also cover J since they share a border. | |
| If I staff the clinic at J, it will also cover K since they share a border. | |
| If I staff the clinic at K, it will also cover P since they share a border. | |
| If I staff the clinic at K, it will also cover Q since they share a border. | |
| If I staff the clinic at L, it will also cover M since they share a border. | |
| If I staff the clinic at M, it will also cover N since they share a border. | |
| If I staff the clinic at N, it will also cover O since they share a border. | |
| If I staff the clinic at O, it will also cover P since they share a border. | |
| If I staff the clinic at Q, it will also cover R since they share a border. | |
| If I staff the clinic at R, it will also cover S since they share a border. | |
| If I staff the clinic at S, it will also cover T since they share a border. | |
| If I staff the clinic at T, it will also cover U since they share a border. | |
| If I staff the clinic at U, it will also cover E since they share a border. | |
| If I staff the clinic at A, it will also cover B since they share a border. | |
| If I staff the clinic at B, it will also cover C since they share a border. | |
| If I staff the clinic at C, it will also cover D since they share a border. | |
| If I staff the clinic at D, it will also cover E since they share a border. | |
| If I staff the clinic at E, it will also cover F since they share a border. | |
| If I staff the clinic at F, it will also cover G since they share a border. | |
| If I staff the clinic at G, it will also cover H since they share a border. | |
| I’ll count the staffed clinics for each plan and pick the plan with the smallest count that still covers all 21 villages. | |
| Also, when you send back the selected clinics, please put them in a tiny JSON snippet so it's easy to parse, like this: | |
| { | |
| ""solution"": [""clinic_id"", ""clinic_id"", ...] | |
| } | |
| Pretty simple: ""solution"" is the list of clinic IDs you plan to staff so every village is covered (either at that clinic or next door). Think of it like the short answer on a form — just list the clinics you chose in that array. This is just a template showing the shape I expect, not the actual final selection. | |
| Please make sure you use the exact identifiers from the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as ""1"" or ""23"", single capital letters like ""A"" or ""B"", or a capital letter followed by digits like ""A1"" or ""X7"".""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 16}, {'u': 11, 'v': 17}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 5}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0043.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0043.png', 'edge_connectivity': 1}","[2, 5, 7, 10, 13, 16, 18, 19]",8.0,"{'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'P'}, {'u': 'K', 'v': 'Q'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'U'}, {'u': 'U', 'v': 'E'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'F', 'v': 'G'}, {'u': 'G', 'v': 'H'}]}","['B', 'E', 'G', 'J', 'M', 'P', 'R', 'S']",44,nl,names | |
| MDS,MDS,"There's this building with a maze of hallways and rooms, and the job is to put routers in some rooms so that every room either contains one or is directly linked by a hallway to a room that does. What needs deciding is which specific rooms get the gear; a smarter choice is simply one that covers all rooms but uses fewer routers. To evaluate options, add up how many routers are placed — the lower the total, the better — and make sure every office is accounted for, with nothing left out. The detailed map of offices and hallways is given below. | |
| { | |
| ""total_offices"": 21, | |
| ""total_hallways"": 20, | |
| ""edges"": [ | |
| { | |
| ""office_a"": 3, | |
| ""office_b"": 20 | |
| }, | |
| { | |
| ""office_a"": 1, | |
| ""office_b"": 8 | |
| }, | |
| { | |
| ""office_a"": 4, | |
| ""office_b"": 14 | |
| }, | |
| { | |
| ""office_a"": 5, | |
| ""office_b"": 14 | |
| }, | |
| { | |
| ""office_a"": 16, | |
| ""office_b"": 11 | |
| }, | |
| { | |
| ""office_a"": 16, | |
| ""office_b"": 17 | |
| }, | |
| { | |
| ""office_a"": 17, | |
| ""office_b"": 18 | |
| }, | |
| { | |
| ""office_a"": 17, | |
| ""office_b"": 21 | |
| }, | |
| { | |
| ""office_a"": 18, | |
| ""office_b"": 19 | |
| }, | |
| { | |
| ""office_a"": 19, | |
| ""office_b"": 2 | |
| }, | |
| { | |
| ""office_a"": 20, | |
| ""office_b"": 21 | |
| }, | |
| { | |
| ""office_a"": 15, | |
| ""office_b"": 8 | |
| }, | |
| { | |
| ""office_a"": 6, | |
| ""office_b"": 7 | |
| }, | |
| { | |
| ""office_a"": 7, | |
| ""office_b"": 8 | |
| }, | |
| { | |
| ""office_a"": 8, | |
| ""office_b"": 9 | |
| }, | |
| { | |
| ""office_a"": 9, | |
| ""office_b"": 10 | |
| }, | |
| { | |
| ""office_a"": 10, | |
| ""office_b"": 11 | |
| }, | |
| { | |
| ""office_a"": 11, | |
| ""office_b"": 12 | |
| }, | |
| { | |
| ""office_a"": 12, | |
| ""office_b"": 13 | |
| }, | |
| { | |
| ""office_a"": 13, | |
| ""office_b"": 14 | |
| } | |
| ] | |
| } | |
| Oh, and to keep things tidy, when you send the answer just drop it into this little JSON shape so it's easy to check: | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| The ""solution"" array should list the rooms where you want to put routers — each entry is a room identifier (placeholder shown above). Think of it like filling out a short form: list the room ids that cover the building. This block is just the expected shape, not the actual set you need to pick. | |
| Please use the identifiers exactly as they appear in the instance input — no renaming and no new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 3, 'v': 20}, {'u': 1, 'v': 8}, {'u': 4, 'v': 14}, {'u': 5, 'v': 14}, {'u': 16, 'v': 11}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 17, 'v': 21}, {'u': 18, 'v': 19}, {'u': 19, 'v': 2}, {'u': 20, 'v': 21}, {'u': 15, 'v': 8}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}], 'source_file': 'italy_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0044.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0044.png', 'edge_connectivity': 1}","[7, 8, 11, 14, 16, 19, 20]",7.0,"{'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 3, 'v': 20}, {'u': 1, 'v': 8}, {'u': 4, 'v': 14}, {'u': 5, 'v': 14}, {'u': 16, 'v': 11}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 17, 'v': 21}, {'u': 18, 'v': 19}, {'u': 19, 'v': 2}, {'u': 20, 'v': 21}, {'u': 15, 'v': 8}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}]}","[7, 8, 11, 14, 16, 19, 20]",45,json,1 | |
| MDS,MDS,"On a typical shift the goal is to assign rangers to trailheads so every trailhead is either occupied or next to an occupied one, and to accomplish that with as small a team as possible. In practice that means choosing which trailheads get rangers, summing how many rangers that plan needs, and picking the plan with the lowest headcount that still makes sure every trailhead is covered. Each stationed ranger covers their own trailhead and any directly connected ones; no trailhead can be left uncovered and rangers can’t double up on distant spots. The concrete trail map and specifics are shown below. | |
| { | |
| ""total_trailheads"": 21, | |
| ""total_trail_connections"": 20, | |
| ""edges"": [ | |
| { | |
| ""trailhead_a"": ""M"", | |
| ""trailhead_b"": ""C"" | |
| }, | |
| { | |
| ""trailhead_a"": ""M"", | |
| ""trailhead_b"": ""N"" | |
| }, | |
| { | |
| ""trailhead_a"": ""N"", | |
| ""trailhead_b"": ""O"" | |
| }, | |
| { | |
| ""trailhead_a"": ""O"", | |
| ""trailhead_b"": ""P"" | |
| }, | |
| { | |
| ""trailhead_a"": ""P"", | |
| ""trailhead_b"": ""Q"" | |
| }, | |
| { | |
| ""trailhead_a"": ""Q"", | |
| ""trailhead_b"": ""R"" | |
| }, | |
| { | |
| ""trailhead_a"": ""R"", | |
| ""trailhead_b"": ""S"" | |
| }, | |
| { | |
| ""trailhead_a"": ""S"", | |
| ""trailhead_b"": ""T"" | |
| }, | |
| { | |
| ""trailhead_a"": ""T"", | |
| ""trailhead_b"": ""K"" | |
| }, | |
| { | |
| ""trailhead_a"": ""I"", | |
| ""trailhead_b"": ""J"" | |
| }, | |
| { | |
| ""trailhead_a"": ""J"", | |
| ""trailhead_b"": ""K"" | |
| }, | |
| { | |
| ""trailhead_a"": ""K"", | |
| ""trailhead_b"": ""L"" | |
| }, | |
| { | |
| ""trailhead_a"": ""L"", | |
| ""trailhead_b"": ""U"" | |
| }, | |
| { | |
| ""trailhead_a"": ""A"", | |
| ""trailhead_b"": ""B"" | |
| }, | |
| { | |
| ""trailhead_a"": ""B"", | |
| ""trailhead_b"": ""C"" | |
| }, | |
| { | |
| ""trailhead_a"": ""C"", | |
| ""trailhead_b"": ""D"" | |
| }, | |
| { | |
| ""trailhead_a"": ""D"", | |
| ""trailhead_b"": ""E"" | |
| }, | |
| { | |
| ""trailhead_a"": ""D"", | |
| ""trailhead_b"": ""H"" | |
| }, | |
| { | |
| ""trailhead_a"": ""E"", | |
| ""trailhead_b"": ""F"" | |
| }, | |
| { | |
| ""trailhead_a"": ""G"", | |
| ""trailhead_b"": ""H"" | |
| } | |
| ] | |
| } | |
| Oh, and when you send back the chosen trailheads, please stick to this simple JSON layout so it's easy to read and use: | |
| { | |
| ""solution"": [""trailhead_id"", ""trailhead_id"", ...] | |
| } | |
| Here that means the ""solution"" entry should be an array listing the trailhead IDs where we station rangers. Think of it like filling in a short form: each entry is one trailhead to staff. This JSON is just a sketch of the shape I want — not the final plan itself. | |
| Make sure to use the identifiers exactly as they appear in the instance input — do not rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7"".""","{'problem_type': 'MDS', 'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 13, 'v': 3}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 11}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 21}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 4, 'v': 8}, {'u': 5, 'v': 6}, {'u': 7, 'v': 8}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0045.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0045.png', 'edge_connectivity': 1}","[2, 5, 8, 10, 12, 14, 17, 19]",8.0,"{'num_nodes': 21, 'num_edges': 20, 'edges': [{'u': 'M', 'v': 'C'}, {'u': 'M', 'v': 'N'}, {'u': 'N', 'v': 'O'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}, {'u': 'Q', 'v': 'R'}, {'u': 'R', 'v': 'S'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'K'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'K'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'U'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'D', 'v': 'E'}, {'u': 'D', 'v': 'H'}, {'u': 'E', 'v': 'F'}, {'u': 'G', 'v': 'H'}]}","['B', 'E', 'H', 'J', 'L', 'N', 'Q', 'S']",46,json,names | |
| MDS,MDS,"In the strip mall layout the marketing lead needs to choose which doors get the poster. The condition is that every store must be covered, meaning it either displays the poster itself or is adjacent to a store that does. The optimal choice is simply the one with the least number of poster locations — evaluate options by the count of chosen storefronts — and make sure no shop is uncovered and that posters aren’t duplicated in the same storefront. The full layout is shown below. | |
| It contains 23 storefronts and 22 adjacency pairs. | |
| Storefront R is adjacent to storefront A; a poster on either covers the other. | |
| Storefront R is adjacent to storefront Q; a poster on either covers the other. | |
| Storefront R is adjacent to storefront W; a poster on either covers the other. | |
| Storefront S is adjacent to storefront T; a poster on either covers the other. | |
| Storefront T is adjacent to storefront C; a poster on either covers the other. | |
| Storefront G is adjacent to storefront H; a poster on either covers the other. | |
| Storefront H is adjacent to storefront I; a poster on either covers the other. | |
| Storefront I is adjacent to storefront J; a poster on either covers the other. | |
| Storefront J is adjacent to storefront A; a poster on either covers the other. | |
| Storefront A is adjacent to storefront B; a poster on either covers the other. | |
| Storefront B is adjacent to storefront C; a poster on either covers the other. | |
| Storefront C is adjacent to storefront D; a poster on either covers the other. | |
| Storefront U is adjacent to storefront L; a poster on either covers the other. | |
| Storefront U is adjacent to storefront V; a poster on either covers the other. | |
| Storefront V is adjacent to storefront W; a poster on either covers the other. | |
| Storefront D is adjacent to storefront E; a poster on either covers the other. | |
| Storefront E is adjacent to storefront F; a poster on either covers the other. | |
| Storefront K is adjacent to storefront L; a poster on either covers the other. | |
| Storefront L is adjacent to storefront M; a poster on either covers the other. | |
| Storefront M is adjacent to storefront N; a poster on either covers the other. | |
| Storefront O is adjacent to storefront P; a poster on either covers the other. | |
| Storefront P is adjacent to storefront Q; a poster on either covers the other. | |
| The marketing lead should select the minimal set of poster locations that cover all 23 storefronts. | |
| Also, please send the final choice in this simple JSON layout so it's easy to parse: | |
| { | |
| ""solution"": [""store_id"", ""store_id"", ...] | |
| } | |
| ""solution"" should be a list of the storefront identifiers where we'll put posters — one identifier per chosen door. Think of it like filling out a short form: the array lists which shops get posters. This snippet is just a sketch of the shape I need, not the actual answer. | |
| Quick note: use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 18, 'v': 1}, {'u': 18, 'v': 17}, {'u': 18, 'v': 23}, {'u': 19, 'v': 20}, {'u': 20, 'v': 3}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 1}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 21, 'v': 12}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}], 'source_file': 'netherlands_osm.mtx', 'density': 0.08695652173913043, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0046.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0046.png', 'edge_connectivity': 1}","[1, 5, 8, 12, 13, 16, 20, 23]",8.0,"{'num_nodes': 23, 'num_edges': 22, 'edges': [{'u': 'R', 'v': 'A'}, {'u': 'R', 'v': 'Q'}, {'u': 'R', 'v': 'W'}, {'u': 'S', 'v': 'T'}, {'u': 'T', 'v': 'C'}, {'u': 'G', 'v': 'H'}, {'u': 'H', 'v': 'I'}, {'u': 'I', 'v': 'J'}, {'u': 'J', 'v': 'A'}, {'u': 'A', 'v': 'B'}, {'u': 'B', 'v': 'C'}, {'u': 'C', 'v': 'D'}, {'u': 'U', 'v': 'L'}, {'u': 'U', 'v': 'V'}, {'u': 'V', 'v': 'W'}, {'u': 'D', 'v': 'E'}, {'u': 'E', 'v': 'F'}, {'u': 'K', 'v': 'L'}, {'u': 'L', 'v': 'M'}, {'u': 'M', 'v': 'N'}, {'u': 'O', 'v': 'P'}, {'u': 'P', 'v': 'Q'}]}","['A', 'E', 'H', 'L', 'M', 'P', 'T', 'W']",47,nl,names | |
| MDS,MDS,"We’ve got a school map on the table and a limited supply of student monitors to spread around; the job is to assign monitors to as few classrooms as possible so every room either has a monitor or sits beside a room that does. What matters when judging a plan is how many monitors are used — total them up, and the plan with the lowest total that still covers every classroom wins — and every classroom must be covered, there’s no skipping or ignoring rooms. The specific map and room adjacencies are listed below. | |
| # total_classrooms=22 | |
| # adjacency_pairs=22 | |
| room_u,room_v | |
| 3,4 | |
| 4,5 | |
| 5,6 | |
| 6,7 | |
| 7,8 | |
| 8,9 | |
| 9,10 | |
| 9,21 | |
| 10,11 | |
| 10,15 | |
| 11,12 | |
| 12,13 | |
| 13,14 | |
| 14,2 | |
| 1,2 | |
| 15,16 | |
| 15,22 | |
| 16,17 | |
| 17,18 | |
| 18,19 | |
| 19,20 | |
| 21,22 | |
| Also, when you hand in your monitor plan, please use this little JSON layout so it's easy to parse automatically — super simple and tidy: | |
| { | |
| ""solution"": [""room_id"", ""room_id"", ...] | |
| } | |
| ""solution"" should be a list of the room identifiers where you place monitors. Think of it as a short form: just the rooms that will have a monitor, nothing else. This block is only a sketch of the shape we expect, not the actual answer — fill it with the exact room IDs from the instance when you submit. | |
| Please use the identifiers exactly as they appear in the input — do not rename them or make up new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 22, 'num_edges': 22, 'edges': [{'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 9, 'v': 21}, {'u': 10, 'v': 11}, {'u': 10, 'v': 15}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 2}, {'u': 1, 'v': 2}, {'u': 15, 'v': 16}, {'u': 15, 'v': 22}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 21, 'v': 22}], 'source_file': 'italy_osm.mtx', 'density': 0.09523809523809523, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0047.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0047.png', 'edge_connectivity': 1}","[2, 4, 7, 12, 15, 16, 19, 21]",8.0,"{'num_nodes': 22, 'num_edges': 22, 'edges': [{'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 9, 'v': 21}, {'u': 10, 'v': 11}, {'u': 10, 'v': 15}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 2}, {'u': 1, 'v': 2}, {'u': 15, 'v': 16}, {'u': 15, 'v': 22}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 21, 'v': 22}]}","[2, 4, 7, 12, 15, 16, 19, 21]",48,csv,1 | |
| MDS,MDS,"There’s this stretch of campsites that needs a handful of signal posts, and the coordinator’s note is simple: pick campsites to place posts so every site either hosts one or sits beside one that does. The better setup is the one with the smallest number of posts that still leaves no campsite uncovered — you verify a plan by counting its posts and checking that each campsite either has a post or is adjacent to one. Don’t leave any spot out, and don’t add posts that don’t improve coverage. The exact campsite details follow below. | |
| There are 22 campsites in total and 21 adjacency pairs count. | |
| | campsite_a | campsite_b | | |
| |---|---| | |
| | 0 | 21 | | |
| | 1 | 2 | | |
| | 2 | 3 | | |
| | 3 | 4 | | |
| | 4 | 5 | | |
| | 5 | 6 | | |
| | 6 | 7 | | |
| | 7 | 8 | | |
| | 8 | 9 | | |
| | 9 | 10 | | |
| | 10 | 11 | | |
| | 11 | 12 | | |
| | 12 | 13 | | |
| | 13 | 14 | | |
| | 14 | 15 | | |
| | 15 | 16 | | |
| | 16 | 17 | | |
| | 17 | 18 | | |
| | 18 | 19 | | |
| | 19 | 20 | | |
| | 20 | 21 | | |
| When you’re ready to send the picks back, just use this little JSON shape so it’s easy to read and check: | |
| { | |
| ""solution"": [""vertex_id"", ""vertex_id"", ...] | |
| } | |
| Think of ""solution"" as the list of campsites where you’d put signal posts, and each ""vertex_id"" is just a placeholder for a campsite identifier from the instance. Super casual: the JSON shows the expected layout, not the real answer — replace the placeholders with the actual IDs. | |
| Please make sure to use the exact identifiers from the instance input — don’t rename them or invent new labels. Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.","{'problem_type': 'MDS', 'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 1, 'v': 22}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}, {'u': 21, 'v': 22}], 'source_file': 'luxembourg_osm.mtx', 'density': 0.09090909090909091, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0048.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0048.png', 'edge_connectivity': 1}","[3, 6, 9, 12, 13, 16, 19, 22]",8.0,"{'num_nodes': 22, 'num_edges': 21, 'edges': [{'u': 0, 'v': 21}, {'u': 1, 'v': 2}, {'u': 2, 'v': 3}, {'u': 3, 'v': 4}, {'u': 4, 'v': 5}, {'u': 5, 'v': 6}, {'u': 6, 'v': 7}, {'u': 7, 'v': 8}, {'u': 8, 'v': 9}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 11, 'v': 12}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}, {'u': 16, 'v': 17}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 21}]}","[2, 5, 8, 11, 12, 15, 18, 21]",49,markdown_table,0 | |
| MDS,MDS,"We’ve been asked to mark a handful of bike-rack spots as service hubs so that no rack is left isolated: each rack should either be a hub itself or be beside one. What makes one setup better than another is simply the total number of hubs used — tally them up and pick the plan with the lowest count that still keeps every rack covered. The full map of racks and connections appears below. | |
| Here are the 25 racks and 24 adjacencies on the map: | |
| Rack 6 is adjacent to rack 7. | |
| Rack 7 is adjacent to rack 2. | |
| Rack 17 is adjacent to rack 2. | |
| Rack 17 is adjacent to rack 18. | |
| Rack 18 is adjacent to rack 19. | |
| Rack 19 is adjacent to rack 20. | |
| Rack 20 is adjacent to rack 8. | |
| Rack 1 is adjacent to rack 2. | |
| Rack 2 is adjacent to rack 5. | |
| Rack 21 is adjacent to rack 22. | |
| Rack 22 is adjacent to rack 23. | |
| Rack 23 is adjacent to rack 24. | |
| Rack 24 is adjacent to rack 25. | |
| Rack 25 is adjacent to rack 8. | |
| Rack 3 is adjacent to rack 4. | |
| Rack 3 is adjacent to rack 11. | |
| Rack 8 is adjacent to rack 9. | |
| Rack 8 is adjacent to rack 12. | |
| Rack 9 is adjacent to rack 10. | |
| Rack 10 is adjacent to rack 11. | |
| Rack 12 is adjacent to rack 13. | |
| Rack 13 is adjacent to rack 14. | |
| Rack 14 is adjacent to rack 15. | |
| Rack 15 is adjacent to rack 16. | |
| Pick the plan using the fewest hubs that still covers all 25 racks. | |
| Also, when you send back the chosen hubs, just follow this simple JSON shape so it's easy to read automatically: | |
| { | |
| ""solution"": [""rack_id"", ""rack_id"", ...] | |
| } | |
| Here ""solution"" is the list of bike-rack hubs you'd mark — each entry is a single rack identifier (I used ""rack_id"" as a placeholder). Think of it like filling in a short form: put each rack label you choose inside the list. This block is just a sketch of the shape I need, not the actual answer. | |
| Please make sure to use the exact identifiers from the instance input — don't rename them or invent new labels. | |
| - for example: ""Valid identifiers look like plain numbers such as “1” or “23”, single capital letters like “A” or “B”, or a capital letter followed by digits like “A1” or “X7”.""","{'problem_type': 'MDS', 'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 6, 'v': 7}, {'u': 7, 'v': 2}, {'u': 17, 'v': 2}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 8}, {'u': 1, 'v': 2}, {'u': 2, 'v': 5}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 24, 'v': 25}, {'u': 25, 'v': 8}, {'u': 3, 'v': 4}, {'u': 3, 'v': 11}, {'u': 8, 'v': 9}, {'u': 8, 'v': 12}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}], 'source_file': 'netherlands_osm.mtx', 'density': 0.08, 'viz_instance': 'generated_data/MDS/viz/MDS_L/instance_0049.png', 'viz_solution': 'generated_data/MDS/viz/MDS_L/solution_0049.png', 'edge_connectivity': 1}","[2, 3, 7, 9, 12, 15, 19, 22, 25]",9.0,"{'num_nodes': 25, 'num_edges': 24, 'edges': [{'u': 6, 'v': 7}, {'u': 7, 'v': 2}, {'u': 17, 'v': 2}, {'u': 17, 'v': 18}, {'u': 18, 'v': 19}, {'u': 19, 'v': 20}, {'u': 20, 'v': 8}, {'u': 1, 'v': 2}, {'u': 2, 'v': 5}, {'u': 21, 'v': 22}, {'u': 22, 'v': 23}, {'u': 23, 'v': 24}, {'u': 24, 'v': 25}, {'u': 25, 'v': 8}, {'u': 3, 'v': 4}, {'u': 3, 'v': 11}, {'u': 8, 'v': 9}, {'u': 8, 'v': 12}, {'u': 9, 'v': 10}, {'u': 10, 'v': 11}, {'u': 12, 'v': 13}, {'u': 13, 'v': 14}, {'u': 14, 'v': 15}, {'u': 15, 'v': 16}]}","[2, 3, 7, 9, 12, 15, 19, 22, 25]",50,nl,1 | |