1 line
9.7 KiB
JSON
1 line
9.7 KiB
JSON
{"repo": "adityajain1030/k4-free-graph-constructions", "files": {"openevolve/examples/tsp_tour_minimization/config.yaml": {"4c13b0e74adf86a2c402d7b9e1b02b70e068b15d": {"t": 1785746312.6264734, "n": 4700, "h": "263a7e291cd87efc", "c": "# Configuration for tsp tour minimization example\nmax_iterations: 10000\nrandom_seed: 42\ncheckpoint_interval: 1\nlanguage: \"mixed\"\nlog_level: \"INFO\"\n\n# LLM configuration\nllm:\n primary_model: \"deepseek-reasoner\"\n primary_model_weight: 1.0\n api_base: \"https://api.deepseek.com\"\n api_key: \"<your-api-key>\"\n temperature: 0.5\n max_tokens: 64000\n timeout: 600\n\n# Prompt configuration\nprompt:\n system_message: |\n You are an expert in the Traveling Salesman Problem (TSP).\n Task:\n Recent papers (2024–2025) have proposed various approaches to the TSP. For example, the UTSP paper introduces a graph neural network (GNN) that generates an n×n heat map of edge probabilities, indicating how likely each edge is to be part of the optimal Hamiltonian cycle. It then applies 2-opt and k-opt (MCTS-based) searches in C++ using this heat map to find the final solution.\n\n However, a later paper (2025) questions the effectiveness of the heat map, showing that 2-opt and k-opt searches perform comparably well—even without it—achieving similar or better solution quality and faster runtime. This approach relies on selecting k-nearest neighbors (KNN) as candidate edges for each city/node.\n\n Your task is to explore a new method or improvement that surpasses the current implementations in terms of the combined score, defined as a function of the average Hamiltonian cycle length and the average time required to produce a solution. I would say that the path length is more important in terms of a combined score than time. For N=1000, the average path length should be about 23.1\n You can use up to 160 seconds of C++ compute (so, maybe it is better to increase `restarts_number` first with new algorithm, and then improve time if needed).\n\n It seems that implementation that uses double type to calc distances is quite slow (in comparison with int32 and int64, that is why the initial program contains implementation in 3 types).\n\n Do not modify the `cities_number` in config.json, as it will be automatically replaced with the appropriate value (1000) during testing. Also, do not modify the `input_path` or `output_path` parameters. All other parameters may be edited.\n Additional information: all test cities were randomly generated within the square [0, 1] × [0, 1] (as is standard in most papers). The number of test samples in a testing batch is 48 (12 cpu cores x 4 launches).\n\n Timeouts (error if exceeds):\n Heat map train: 480 seconds.\n Heat map inference: 60 seconds per instance.\n TSP compilation: 10 seconds.\n TSP run: 160 seconds per instance (as in the SOTA 2024 paper for N=1000).\n \n If training heat map, do not forget to clean GPU (cuda:0) entirely before starting training procedure. Environment characteristics: python3.11, ubuntu 22.04, nvidia A100 40 GB GPU.\n \n The C++ program will be compiled using C++ 17 standart. The compilation command: \"g++ -std=gnu++17 -O3 -DNDEBUG -march=native -funroll-loops -ffast-math -Iinclude TSP.cpp -o bin/runner -lpthread -lm -ldl\" (may slightly vary depending on the operation system)\n The C++ program is implemented in a way that supports double, int32 (int) and int64 (long long) distance calculations that is specified in runtime in config.json (that you can change).\n\n You can — and probably should — write something to stdout for yourself. This stdout output will be shown to you in future calls.\n\n programs_as_changes_description: true\n\n system_message_changes_description: |\n Important: Describe your changes and any new methods in the \"Changes Description\" field, replacing the previous description first (as usual, using SEARCH & REPLACE blocks). If you skip this step, all proposed changes will be discarded because our evolution algorithm depends on it.\n It is recommended to write the description in plain language as a short numbered list (avoid long paragraphs and complex symbols), since a different LLM model (or you later) will need to update this text in future calls.\n \n initial_changes_description: |\n Default workflow from the 2024 paper \"UTSP\" implementing 2'opt and k'opt searches.\n No further changes.\n\n include_artifacts: true\n num_top_programs: 3\n num_diverse_programs: 2\n suggest_simplification_after_chars: 60000\n concise_implementation_max_lines: 1000\n comprehensive_implementation_min_lines: 5000\n\n# Database configuration\ndatabase:\n population_size: 100\n archive_size: 40\n num_islands: 3\n elite_selection_ratio: 0.2\n exploitation_ratio: 0.7\n\n# Evaluator configuration\nevaluator:\n timeout: 1500\n cascade_evaluation: false\n parallel_evaluations: 3\n\n# Evolution settings\ndiff_based_evolution: true\nmax_code_length: 150000\n"}, "4dfcb712009e065a71319088b7787b8967be11ae": {"t": 1785761675.118237, "n": 4700, "h": "263a7e291cd87efc", "c": "# Configuration for tsp tour minimization example\nmax_iterations: 10000\nrandom_seed: 42\ncheckpoint_interval: 1\nlanguage: \"mixed\"\nlog_level: \"INFO\"\n\n# LLM configuration\nllm:\n primary_model: \"deepseek-reasoner\"\n primary_model_weight: 1.0\n api_base: \"https://api.deepseek.com\"\n api_key: \"<your-api-key>\"\n temperature: 0.5\n max_tokens: 64000\n timeout: 600\n\n# Prompt configuration\nprompt:\n system_message: |\n You are an expert in the Traveling Salesman Problem (TSP).\n Task:\n Recent papers (2024–2025) have proposed various approaches to the TSP. For example, the UTSP paper introduces a graph neural network (GNN) that generates an n×n heat map of edge probabilities, indicating how likely each edge is to be part of the optimal Hamiltonian cycle. It then applies 2-opt and k-opt (MCTS-based) searches in C++ using this heat map to find the final solution.\n\n However, a later paper (2025) questions the effectiveness of the heat map, showing that 2-opt and k-opt searches perform comparably well—even without it—achieving similar or better solution quality and faster runtime. This approach relies on selecting k-nearest neighbors (KNN) as candidate edges for each city/node.\n\n Your task is to explore a new method or improvement that surpasses the current implementations in terms of the combined score, defined as a function of the average Hamiltonian cycle length and the average time required to produce a solution. I would say that the path length is more important in terms of a combined score than time. For N=1000, the average path length should be about 23.1\n You can use up to 160 seconds of C++ compute (so, maybe it is better to increase `restarts_number` first with new algorithm, and then improve time if needed).\n\n It seems that implementation that uses double type to calc distances is quite slow (in comparison with int32 and int64, that is why the initial program contains implementation in 3 types).\n\n Do not modify the `cities_number` in config.json, as it will be automatically replaced with the appropriate value (1000) during testing. Also, do not modify the `input_path` or `output_path` parameters. All other parameters may be edited.\n Additional information: all test cities were randomly generated within the square [0, 1] × [0, 1] (as is standard in most papers). The number of test samples in a testing batch is 48 (12 cpu cores x 4 launches).\n\n Timeouts (error if exceeds):\n Heat map train: 480 seconds.\n Heat map inference: 60 seconds per instance.\n TSP compilation: 10 seconds.\n TSP run: 160 seconds per instance (as in the SOTA 2024 paper for N=1000).\n \n If training heat map, do not forget to clean GPU (cuda:0) entirely before starting training procedure. Environment characteristics: python3.11, ubuntu 22.04, nvidia A100 40 GB GPU.\n \n The C++ program will be compiled using C++ 17 standart. The compilation command: \"g++ -std=gnu++17 -O3 -DNDEBUG -march=native -funroll-loops -ffast-math -Iinclude TSP.cpp -o bin/runner -lpthread -lm -ldl\" (may slightly vary depending on the operation system)\n The C++ program is implemented in a way that supports double, int32 (int) and int64 (long long) distance calculations that is specified in runtime in config.json (that you can change).\n\n You can — and probably should — write something to stdout for yourself. This stdout output will be shown to you in future calls.\n\n programs_as_changes_description: true\n\n system_message_changes_description: |\n Important: Describe your changes and any new methods in the \"Changes Description\" field, replacing the previous description first (as usual, using SEARCH & REPLACE blocks). If you skip this step, all proposed changes will be discarded because our evolution algorithm depends on it.\n It is recommended to write the description in plain language as a short numbered list (avoid long paragraphs and complex symbols), since a different LLM model (or you later) will need to update this text in future calls.\n \n initial_changes_description: |\n Default workflow from the 2024 paper \"UTSP\" implementing 2'opt and k'opt searches.\n No further changes.\n\n include_artifacts: true\n num_top_programs: 3\n num_diverse_programs: 2\n suggest_simplification_after_chars: 60000\n concise_implementation_max_lines: 1000\n comprehensive_implementation_min_lines: 5000\n\n# Database configuration\ndatabase:\n population_size: 100\n archive_size: 40\n num_islands: 3\n elite_selection_ratio: 0.2\n exploitation_ratio: 0.7\n\n# Evaluator configuration\nevaluator:\n timeout: 1500\n cascade_evaluation: false\n parallel_evaluations: 3\n\n# Evolution settings\ndiff_based_evolution: true\nmax_code_length: 150000\n"}}}} |