Start with 100 grid points, ten across and ten down. Choose some of them and join every pair. The rule is that no two of those segments may be parallel. Each extra point creates a segment to every point already chosen, so an apparently spacious grid quickly becomes restrictive.
A valid ten-point arrangement was already public. I used it as the starting point for a project that checked every possible eleven-point configuration and assembled the material needed to rerun that check. The maximum came out as ten. I kept the existing arrangement's source visible and paired the eleven-point exclusion with the search code and completed logs.
Different lengths can still repeat a direction
A segment that moves one unit across and one up is parallel to one that moves two across and two up. Their lengths differ, but this problem does not allow both. Reversing a segment does not create a new direction, and vertical segments count too. This is the distinct undirected-slope condition.
The conflicting segments do not have to be disjoint. Three collinear points already produce multiple pairs with the same direction. There is, however, no separate rule requiring one point per row or column. Repeated rows and columns are allowed whenever the full set of directions remains distinct.
The arrangement I used comes from TheoremDB R228. Coordinates run from 0 to 9 in each direction, with (0,0) at the lower left.
(0,7), (1,2), (2,0), (4,6), (5,3),
(6,9), (7,1), (8,1), (9,5), (9,8)
Ten points determine 10 × 9 / 2 = 45 unordered pairs. Checking the segments gives 45 distinct directions. The points (7,1) and (8,1) share a row; (9,5) and (9,8) share a column. Imposing a one-per-row-and-column condition would discard this valid example.
That establishes that ten points are possible. To determine a maximum, I also needed a check of whether some other arrangement could contain eleven.
Why 450 starting cases cover every eleven-point candidate
The search begins with the vertical direction. Three points in one column produce repeated vertical segments. Two different columns containing two points each do the same. Consequently, a column can contain at most two points, and only one column can contain two.
With ten columns, this gives an upper bound of eleven. An eleven-point configuration must use every column: exactly one holds two points and the other nine hold one each. Configurations of twelve or more points are already excluded by this argument.
There are ten choices of the doubled column and 10 × 9 / 2 = 45 choices of its two heights. That gives 10 × 45 = 450 starting cases. From each one, the column search fills the remaining columns in order, trying every height from 0 to 9. It does not remove cases by rotation or reflection symmetry.
When inserting a point, the program checks every new segment against the directions already present and against the other segments created by that insertion. A repeated direction ends that branch. This is safe because adding more points cannot remove two parallel segments that already exist.
Conversely, any valid eleven-point arrangement determines exactly one doubled column and pair of heights. Its remaining heights appear among the branches, and every partial arrangement must also satisfy the direction rule. It would therefore survive to a complete configuration. This correspondence supplies the coverage argument. A large operation count alone would not establish completeness.
Comparing different implementations
The direction test avoids decimal slopes. It represents a difference between points as (dx, dy), divides both integers by their greatest common divisor—the largest positive integer that divides both—and fixes the sign. Thus (2,2) and (1,1) both become (1,1). Vertical direction becomes (0,1), with no division by zero. There are 112 possible undirected directions in the full grid.
The first C++ implementation assigns those directions integer IDs and records which IDs are used as it fills columns. A second C++ implementation fills rows instead. It uses neither direction IDs nor greatest common divisors, testing parallelism through integer products: two direction vectors u=(uₓ,uᵧ) and v=(vₓ,vᵧ) are parallel exactly when
uₓ × vᵧ = uᵧ × vₓ
A separate JavaScript implementation prioritises unfilled rows with fewer legal positions. It changes the search order while still branching over every allowed position. I organised the verification material around the rejection rules and completed outputs of these implementations, so their agreement could be examined alongside the coverage argument.
In the table below, a recursive call means invoking the search function to continue from the points placed so far. The checks of whether a new point can be inserted are counted separately.
| Search implementation | Recursive calls visited | Proposed point insertions examined | Eleven-point solutions |
|---|---|---|---|
| C++: columns, integer direction IDs | 2,313,008 | 23,130,080 | 0 |
| C++: rows, integer-product comparison | 1,363,055 | 14,552,996 | 0 |
| JavaScript: most constrained row first | 1,310,942 | 29,067,520 | 0 |
These are counts of intermediate states and insertion checks, not completed configurations. The JavaScript search also checks positions while choosing its next row, so the counters are not a direct speed or efficiency ranking. All three searches finished without a time cutoff and found no eleven-point solution.
The package also records small cases that check whether the programs discard valid configurations. For grids with 2, 3, 4 and 5 points along each side, each check used one more point than the side length: respectively 3, 4, 5 and 6 points. The numbers of valid sets were 4, 28, 112 and 48, matching between the row-based C++ search and direct Python enumeration of every subset. Those controls can reveal implementation errors; they do not replace complete coverage of the ten-by-ten case.
On 6 September 2026, the grid-checking functions of the public JavaScript implementation were rerun. They again verified the ten-point witness's 45 distinct directions, completed all 450 starting cases and returned zero eleven-point solutions. The recursive-call and insertion-check counters matched the JavaScript row of the table. The two C++ programs were not rerun in that follow-up check; their table entries come from the execution records preserved in the public package.
What was already known, and what I made available
The value ten had been reported before this project. TheoremDB R5991 records it under pnv on 19 August 2026. That record checks a ten-point witness but relies on a source report for the global eleven-point exclusion; its text explicitly says the larger search was not rerun there. Its evidence grade at this check was self_reported.
I retained that prior report in the note and framed this contribution as executable verification of the known value. The original numerical table in Peile and Taylor's 2000 paper remained unavailable for direct inspection in this source comparison, so I did not assign a value to its ten-by-ten entry. That unresolved table access does not erase the earlier report or support a first-discovery claim.
Rerunning the computation
The Zenodo preprint and reproducibility package, published on 5 September 2026, combine F03 with another finite-search problem, F01. From the extracted archive's root directory, the recorded verification can be followed with either command below. Both commands check F01 as well as F03.
python3 verify_all.py REPLAY_NEW
node independent_verifier.js .
The first route requires Linux or WSL, Python 3.10 or later, and g++ or clang++ with C++17 support. Its preserved run used Python 3.12.3 and g++ 13.3.0.
The second route has a recorded run under Node.js 24.19.0. It reads the shared witness data but imports none of the supplied Python or C++ mathematical implementations. Neither route requires an optimisation solver, a GPU or a network connection during verification.
Contributions and review status
My role was to supply the problem material and direct the project and scope of public release. ChatGPT Pro contributed the mathematical reductions, search code, initial computations and explanation. Codex inspected the files, replayed computations, checked prior sources, performed additional computational audits and prepared the public note. The existing ten-point witness remains credited in both the manuscript and its data file.
As checked on 6 September 2026, my research record R11761 is registered as completed, with evidence grade computational. The parent problem P2682 remains Open: a complete resolution has not passed its review. Agreement between implementations and the supplementary checks constitute internal computational verification, without external human peer review or certification by a formal proof kernel.
The files now let a reader follow both a feasible ten-point example and the search excluding eleven. They make the finite computation inspectable and repeatable, including the places where a reviewer could challenge coverage or an invalid rejection rule.
