Reduction Lab — learner starter

This is a fresh learner exercise, not a completed project. reduction.cpp deliberately reports LEARNER_TODO; the initial complete tests must fail. Build success is only a scaffold check. Save your implementation in a separate learner directory; keep the provided starter and its evidence intact.

First entry and file roles

Enter after G0 and SYS-00 fixed-width interfaces. Reuse 16.4’s placeholder and discarded-value reading for the existing logic_error and (void) lines. This README specifies the project contract, build commands and tasks; chapters own the C++ teaching.

Contract

• Use ISO C++20. Input length is at most 1,000,000; every integer is in [-1,000,000, 1,000,000]. Reject values outside this domain with std::invalid_argument before computing.
• Return the exact int64_t sum. The bounded domain keeps every subset sum within +/-1e12, so signed overflow is not needed or permitted. Empty input sums to zero.
• Parallel mode accepts 1–64 workers; reject zero and values above 64. Threads join before their data is read. Explain partition boundaries and ownership.
• First implement sequential correctness. Then parallel correctness. Only then collect performance data. Do not label CPU results GPU results.

1 · Sequential work with a runnable check of your own

Read the contract and sequential declaration, write predictions, then implement only sequential in your learner copy. Create your own sequential_tests.cpp using the independently written expectation and registration checks from 18.1–18.2. Start with empty input, one element, zeros, mixed signs, both allowed value endpoints, a value just outside each endpoint, and the allowed length boundary. Give each test an explicit expected result or expected rejection. Do not call sum_parallel in this first harness.

Once you have written those two learner files, this is the standalone build/run path from their directory:

clang++ -std=c++20 -Wall -Wextra -Wpedantic -Werror -pthread reduction.cpp sequential_tests.cpp -o sequential_tests
./sequential_tests

This command is a task instruction, not a claim that a sequential_tests.cpp already exists or that your implementation passed. Keep the main function in your test file; reduction.cpp supplies the implementation. The original complete tests.cpp and learner_correctness CTest target still call the unfinished parallel function; their expected failure does not invalidate a separately demonstrated sequential milestone, and must not be hidden by deleting checks.

2 · Parallel and random cases at their own entry points

Before adding random tests, complete the independent Chapter 30: seeded-input-contract and its same-source small program. Then apply that interface reading to this project’s seed 20260905 and interval [-1000000,1000000]. Keep the fixed boundary cases and save generated input data; do not treat the word “seed” as sufficient preparation to read the harness.

Before parallel work, complete Chapter 25’s thread state and capture contracts and Chapter 31’s partitioning. Start with the assigned fixed eight-element/two-task prototype, then generalize to the bounded worker range. Draw partitions, compare against your verified sequential function, and include empty tasks and more workers than elements. The provided TODO is not a completed answer.

Only read and run the full tests.cpp at the complete acceptance stage: both implementations, random-input reading, and NET N3’s exception/what/cerr usage must be available. The existing rejection wrapper and (void) calls remain; use 16.4 when reading them. Downloading a harness earlier does not require predicting every line at the first sequential task.

3 · Full build and acceptance

After the complete-harness prerequisites, compile the existing full target directly:

clang++ -std=c++20 -Wall -Wextra -Wpedantic -Werror -pthread reduction.cpp tests.cpp -o reduction_tests
./reduction_tests

An unimplemented starter reports LEARNER_TODO. With CMake installed, the provided full build commands are:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build
ctest --test-dir build --output-on-failure
cmake -S . -B build-release -DCMAKE_BUILD_TYPE=Release
cmake --build build-release
./build-release/reduction_bench > samples.csv
cmake -S . -B build-san -DCMAKE_BUILD_TYPE=Debug -DENABLE_SANITIZERS=ON
cmake --build build-san
ctest --test-dir build-san --output-on-failure

本项目的构建开关（另估15分钟）

基础目标与编译选项读法沿用17。以下是配置文件中额外几行的操作说明；不需要实现CMake才能构建这个项目。

三个构建目录可分别保留Debug、Release和sanitizer配置；修改源码后仍须构建相应目标。sanitizer的验证边界见18.4。这15分钟是操作阅读粗估，另加到原项目预算；它不代表学习者实现已经通过。

操作依据：CMake option、FindThreads、add_test、CTest命令。

4 · Measure only after correctness

Before reading benchmark.cpp, complete NET N6’s time-point/duration chain and Chapter 30’s nanosecond reading and measurement boundaries. The full tests.cpp has no chrono call; this prerequisite prepares the subsequent benchmark, rather than attributing a nonexistent API to the tests.

The benchmark validates each result outside its timed region and performs a warm-up before seven samples per size/worker combination. Record compiler, flags, OS, CPU, power mode and background load alongside CSV. Compare like with like; the benchmark includes thread creation when workers > 1. Its supplied sizes start at 1000, so the required zero-input correctness case belongs in your earlier tests; do not claim that benchmark.cpp already measures it. Do not infer device properties from the numbers.

Finish with your prediction, code, independent tests, partition drawing, raw samples and a five-minute explanation using a new input/worker variation. The teaching examples have answers; this starter intentionally does not. This documentation-only migration changed no CPP, HPP, TODO, CMake configuration, runner, execution receipt or personal mastery record.