|
Последний раз редактировалось Klein 10.07.2026, 20:47, всего редактировалось 4 раз(а).
Правда, я не знаю на чём Вы запускали.
Присоединяюсь к вопросу mihaild. О чём Вы спрашивали у ИИ ?
К ответу на предыдущей странице - промпт ниже. ПС Саму программу (которая работает медленнее) я писать не планировал и даже не разбирался, что именно сделала модель: просто попросил ее написать программу на C. Можно попросить модель оптимизировать код и определить, какие его участки замедляют работу программы. Prompt . Скриншот вашего сообщения прилагался.
- "You are the lead computational mathematician, algorithm designer, and
- high-performance-computing engineer for this project.
-
- Your task is not merely to recommend a programming language or libraries.
- You must formalise the counting problem, select an appropriate technical
- stack, implement a correct exact counter, verify it independently, optimise
- it, and benchmark it.
-
- PROJECT GOAL
-
- Develop a fast, memory-efficient, reproducible program that exactly counts
- the admissible objects represented by the attached table. The program must
- reproduce all known rows and scale to substantially larger diameters.
-
- Use the attached screenshot as a regression reference:
-
- @table.png
-
- Read all relevant files already present in the repository, including:
-
- @AGENTS.md
- @README.md
- @problem_statement.md
- @notes/
- @src/
- @tests/
-
- The exact mathematical definition of the objects being counted is:
-
- [PASTE THE COMPLETE MATHEMATICAL DEFINITION HERE]
-
- The definition must specify, at minimum:
-
- 1. What constitutes an object or admissible variant.
- 2. What “diameter” means.
- 3. What the columns numbered 0, 1, 2, ... represent.
- 4. What the phrase “pattern of contaminating primes” means in this problem.
- 5. Whether objects related by reflection, rotation, translation, relabelling,
- permutation, or another symmetry are regarded as identical.
- 6. Whether objects are labelled or unlabelled.
- 7. All admissibility restrictions.
- 8. Whether blank table entries mean zero or “not applicable”.
-
- IMPORTANT SPECIFICATION RULE
-
- The screenshot and the numerical table are test data, not a complete
- mathematical specification. Do not infer the definition solely by fitting a
- recurrence or extrapolating the displayed numbers.
-
- First search the repository for the complete definition. If the definition
- cannot be recovered unambiguously, stop before implementing the production
- counter and ask me the smallest possible set of precise mathematical
- questions needed to remove the ambiguity.
-
- KNOWN REGRESSION VALUES
-
- The vectors below reproduce the values visible in the screenshot. Index i
- corresponds to column i:
-
- diameter 2: [1]
- diameter 4: [1]
- diameter 6: [2, 2]
- diameter 8: [1, 2, 1]
- diameter 10: [4, 6, 2]
- diameter 12: [6, 14, 10, 2]
- diameter 14: [18, 40, 28, 6]
- diameter 16: [15, 40, 36, 12, 1]
- diameter 18: [30, 92, 100, 44, 6]
- diameter 20: [20, 78, 116, 80, 24, 2]
- diameter 22: [150, 504, 632, 350, 72]
- diameter 24: [270, 1088, 1738, 1376, 540, 84]
- diameter 26: [1620, 6688, 11090, 9378, 4224, 952, 84]
-
- Confirm these values against the attached screenshot and the formal
- definition before treating them as authoritative.
-
- ULTRA-MODE DELEGATION
-
- Use independent subagents where useful. In particular, delegate the following
- workstreams and require them to report their reasoning and evidence separately:
-
- 1. Formal-specification agent
- - Translate the informal statement into precise mathematical definitions.
- - Identify the equivalence relation and possible symmetries.
- - Derive invariants, recurrences, generating functions, or decompositions.
- - Check whether the published table is internally consistent.
-
- 2. Algorithm-design agent
- - Develop several exact algorithms.
- - Consider dynamic programming, transfer matrices, generating functions,
- canonical augmentation, symmetry reduction, memoisation, branch and
- bound, meet-in-the-middle methods, SAT/SMT formulations, exact-cover
- methods, graph-isomorphism tools, and other relevant techniques.
- - Analyse asymptotic time and memory complexity.
-
- 3. Systems-and-performance agent
- - Compare practical implementation stacks.
- - Prototype the most promising alternatives.
- - Profile CPU time, memory use, allocation behaviour, cache behaviour,
- parallel scalability, and big-integer costs.
-
- 4. Independent-verification agent
- - Write a deliberately simple reference implementation.
- - Derive independent checks, identities, invariants, and test cases.
- - Perform differential testing against the optimised implementation.
- - Investigate Mathematica, Maple, SageMath, Lean 4, SAT/SMT, or another
- independent tool where this materially increases confidence.
-
- The lead agent must reconcile disagreements between the subagents. Do not
- accept agreement produced merely by copying the same implementation or
- algorithm.
-
- PHASE 1 — FORMALISE THE PROBLEM
-
- Before choosing a language:
-
- 1. Write a precise specification in SPEC.md.
- 2. Define exactly what is counted in each table cell.
- 3. State the symmetry or equivalence relation.
- 4. Give at least two small hand-checkable examples.
- 5. Explain why the known rows should have their stated values.
- 6. Identify all assumptions and possible ambiguities.
- 7. Determine whether only even diameters are valid, rather than assuming this
- from the supplied table.
- 8. Determine whether counts can exceed 64-bit integer range at the intended
- problem sizes.
-
- Do not begin performance optimisation until the specification is sufficiently
- precise to support independent implementation.
-
- PHASE 2 — DERIVE AND COMPARE ALGORITHMS
-
- Develop at least:
-
- A. A simple exhaustive or brute-force reference algorithm suitable for small
- diameters.
-
- B. A mathematically improved exact algorithm intended for large diameters.
-
- Where applicable, investigate:
-
- - elimination of equivalent states by canonicalisation;
- - Burnside’s lemma or orbit counting;
- - state compression and bit-packed representations;
- - recurrence relations;
- - dynamic programming over canonical boundary states;
- - transfer-matrix methods;
- - sparse polynomial or generating-function computations;
- - memoisation of isomorphic subproblems;
- - precomputation of compatibility relations;
- - branch ordering and branch-and-bound;
- - meet-in-the-middle decompositions;
- - bitsets and word-level parallelism;
- - incremental generation rather than generate-and-filter;
- - work partitioning across CPU cores;
- - checkpointing and restart support.
-
- For every serious candidate algorithm, report:
-
- - correctness argument;
- - state-space size;
- - expected time complexity;
- - expected memory complexity;
- - parallelisation opportunities;
- - implementation risk;
- - predicted scaling bottleneck.
-
- Do not select an algorithm merely because it is easy to code.
-
- PHASE 3 — SELECT THE TECHNICAL STACK
-
- Decide empirically which languages, libraries, build tools, and supporting
- software are appropriate.
-
- Do not default automatically to Python, C++, Rust, Julia, Mathematica, or any
- other language. Compare realistic candidates based on this specific problem.
-
- Candidate stacks may include, but are not limited to:
-
- - C++23 with Boost.Multiprecision, GMP, FLINT, OpenMP, oneTBB, or specialised
- graph/combinatorics libraries;
- - Rust with rayon, hashbrown, fixedbitset, num-bigint, rug/GMP, or suitable
- canonicalisation libraries;
- - Julia with specialised exact-arithmetic and combinatorics packages;
- - Python as a transparent reference implementation, potentially combined with
- Cython, Numba, pybind11, Rust, or C++ for performance-critical kernels;
- - Mathematica, Maple, or SageMath for symbolic derivation and independent
- verification;
- - Lean 4 for formalising a key recurrence, invariant, or correctness theorem
- if the formalisation is practical;
- - SAT/SMT, exact-cover, or graph-isomorphism software if the mathematical
- structure makes those tools appropriate.
-
- For the final stack decision, provide a decision matrix covering:
-
- - correctness and exact arithmetic;
- - development time;
- - execution speed;
- - memory efficiency;
- - multicore support;
- - availability of arbitrary-precision integers;
- - quality of profiling and debugging tools;
- - portability;
- - reproducibility;
- - maintenance burden.
-
- Prototype and benchmark the most plausible alternatives rather than relying
- only on general assumptions about language speed.
-
- Use exact integer arithmetic. Floating-point approximations must not be used
- for final counts.
-
- If fixed-width integers are used as an optimisation, add checked overflow and
- a safe automatic or configurable transition to arbitrary-precision integers.
-
- Do not use a GPU unless the computation maps naturally to GPU hardware and a
- benchmark demonstrates a real end-to-end advantage.
-
- PHASE 4 — IMPLEMENTATION
-
- Create:
-
- 1. A small, readable reference implementation.
- 2. A production-quality optimised implementation.
- 3. A command-line interface such as:
-
- counter --diameter 26
- counter --max-diameter 40
- counter --threads auto
- counter --output results.csv
- counter --checkpoint checkpoints/run01
- counter --resume checkpoints/run01
-
- 4. Machine-readable output in CSV or JSON.
- 5. Human-readable output matching the table format.
- 6. Deterministic execution by default.
- 7. Progress reporting for long computations.
- 8. Checkpoint and resume support if runs can last more than a few minutes.
- 9. Explicit error handling and validation of command-line arguments.
- 10. Documentation of memory and disk requirements.
-
- Separate the mathematical logic from input/output, parallel orchestration, and
- performance-specific code.
-
- Avoid unnecessary dependencies and avoid modifying unrelated repository files.
-
- PHASE 5 — VERIFICATION
-
- Correctness is more important than speed.
-
- Use several independent layers of verification:
-
- 1. Reproduce every known row from diameter 2 through diameter 26 exactly.
- 2. Compare the optimised implementation with the simple reference
- implementation on every size for which brute force is feasible.
- 3. Add unit tests for all local rules and transformations.
- 4. Add property-based tests for invariants.
- 5. Test canonicalisation and symmetry handling independently.
- 6. Test single-threaded and multithreaded runs for identical results.
- 7. Test boundary cases and invalid input.
- 8. Run integer-overflow checks.
- 9. Use sanitizers, static analysis, or equivalent language-specific tools.
- 10. Where practical, implement one independent cross-check in a different
- language or mathematical system.
- 11. If a recurrence is used, provide a mathematical proof or a sufficiently
- detailed derivation that can be reviewed independently.
- 12. If feasible, formalise the central recurrence or invariant in Lean 4, but
- do not allow optional formalisation to block completion of the verified
- executable counter.
-
- A fast program that reproduces the table only because it was fitted to the
- known outputs is unacceptable.
-
- PHASE 6 — PROFILING AND OPTIMISATION
-
- Establish a baseline before optimising.
-
- Measure at least:
-
- - wall-clock time;
- - CPU time;
- - peak resident memory;
- - allocations;
- - number of generated states;
- - number of retained canonical states;
- - memoisation hit rate;
- - time spent in hashing and canonicalisation;
- - scaling from 1 to the available number of CPU cores;
- - big-integer overhead, if applicable.
-
- Use appropriate profilers and benchmark tools for the selected stack.
-
- Optimise measured bottlenecks rather than guessed bottlenecks.
-
- Consider:
-
- - compact state encodings;
- - custom hashes;
- - sorted vectors versus hash tables;
- - structure-of-arrays versus array-of-structures layouts;
- - memory pools or arenas;
- - reducing allocations;
- - avoiding repeated canonicalisation;
- - precomputed transition tables;
- - cache-friendly traversal;
- - batch processing;
- - work stealing;
- - deterministic parallel reduction;
- - serialisation of reusable intermediate data.
-
- Retain the readable reference version even after the production version has
- been optimised.
-
- BENCHMARK REQUIREMENTS
-
- Benchmark the reference and optimised implementations on the current machine.
-
- Report:
-
- 1. Hardware, operating system, compiler/interpreter, and dependency versions.
- 2. Exact build commands and compiler flags.
- 3. Runtime and peak memory for each feasible diameter.
- 4. Speed-up relative to the reference implementation.
- 5. Parallel efficiency for several thread counts.
- 6. The largest diameter completed within approximately:
- - one minute;
- - ten minutes;
- - one hour,
- where practical.
- 7. A reasoned projection of scaling beyond the measured range.
- 8. Any point at which arbitrary-precision arithmetic becomes necessary.
-
- Do not present extrapolated runtimes as measured results.
-
- DELIVERABLES
-
- Produce the following:
-
- - AGENTS.md
- Persistent project instructions and verification requirements.
-
- - SPEC.md
- Formal mathematical definition and assumptions.
-
- - DESIGN.md
- Candidate algorithms, correctness arguments, complexity analysis, stack
- comparison, and final technical decision.
-
- - README.md
- Build, installation, execution, verification, and benchmark instructions.
-
- - src/
- Production implementation.
-
- - reference/
- Simple independent implementation.
-
- - tests/
- Unit, regression, property, and differential tests.
-
- - benchmarks/
- Benchmark scripts and raw benchmark results.
-
- - results/
- Generated CSV or JSON tables.
-
- - environment or lock files
- Reproducible dependency versions.
-
- - FINAL_REPORT.md
- A concise account of:
- - the selected algorithm;
- - the selected language and libraries;
- - why they were selected;
- - proof or argument for correctness;
- - verification results;
- - performance results;
- - remaining bottlenecks;
- - recommended next optimisation steps.
-
- PERMISSIONS AND SECURITY
-
- You may:
-
- - inspect all project files;
- - create and modify files inside this repository;
- - compile and run code;
- - create an isolated virtual environment or toolchain;
- - install project-local dependencies;
- - use the available CPU cores for benchmarks.
-
- Ask before:
-
- - making system-wide changes;
- - requesting administrator privileges;
- - changing WSL or host operating-system configuration;
- - installing proprietary software;
- - transmitting project data to an external service;
- - running a benchmark expected to consume very large amounts of memory,
- storage, or time.
-
- Use official package managers and pinned dependencies. Do not execute
- unreviewed “curl | shell” installation commands.
-
- EXECUTION POLICY
-
- Begin by inspecting the repository and formalising the task.
-
- Do not ask me which programming language to choose: selecting and justifying
- the stack is part of your task.
-
- Do not stop after producing a plan or a list of recommendations. Continue
- through implementation, verification, profiling, and documentation unless a
- missing mathematical definition makes correct implementation impossible.
-
- Ask questions only when they are necessary to prevent an incorrect
- interpretation of the mathematical problem.
-
- At the end, give me:
-
- 1. The exact counts obtained.
- 2. Confirmation of whether every supplied regression value matched.
- 3. The chosen language, libraries, and tools.
- 4. The measured runtime and memory usage.
- 5. The commands required to reproduce the result.
- 6. Any unresolved mathematical or computational uncertainty.
|
