What the endpoint means in the implemented formula
With no gates, this tool calculates sections = ceil(length / spacing), then posts = sections + 1. The additional item belongs to its open-run planning model. There is no open-or-closed selector, rectangle width, rectangle length or shared-corner field.
A hypothetical 96 ft input with 8 ft spacing and no gates returns 12 sections and 13 posts. That actual-handler result is the same whether you intended a straight line or silently meant a perimeter: the form receives the same inputs. It cannot recover the shape from the number 96.
A defined loop counts shared vertices differently
For a separate arithmetic comparison, imagine a square with four 24 ft sides. Divide each side into three intervals. Assume adjacent sides meet at a single shared vertex, the final side rejoins the first vertex, and there are no gates. This is an ideal interval diagram, not a physical fence system or a recommended spacing.
The diagram has 3 + 3 + 3 + 3 = 12 intervals and 12 unique vertices around the closed loop. Alternatively, count four open side diagrams: each has 3 + 1 = 4 vertices, for 16 entries. Each of the four corner vertices was then entered twice, so deduplication gives 16 − 4 = 12.
The tool's single 96 ft open-run count remains 13 posts. The diagram's 12 vertices are independently calculated; they are not a closed-loop result supplied by the calculator. A diagram vertex must not automatically be equated with one physical post in every fence system.
Equal perimeters can hide different side boundaries
A second hypothetical rectangle has sides of 20 ft and 28 ft, also totaling 2 × (20 + 28) = 96 ft. For this comparison only, partition each side into ceil(side length / 8) intervals, including its two corners as endpoints. Redistribute the intervals within each side; do not treat their lengths as measured post positions.
| Hypothetical sides | Perimeter | Separate side intervals | Unique loop vertices under stated assumptions | Actual single-run tool posts |
|---|---|---|---|---|
| 24, 24, 24, 24 ft | 96 ft | 3 + 3 + 3 + 3 = 12 | 12 | 13 |
| 20, 28, 20, 28 ft | 96 ft | 3 + 4 + 3 + 4 = 14 | 14 | 13 |
The second diagram's four open-side vertex lists contain 4 + 5 + 4 + 5 = 18 entries. Deduplicating the four shared corners leaves 14. The difference comes from the defined side boundaries and separate rounding, not a price or a product specification.
These comparisons show why subtracting one from every perimeter-based result is not a general correction. One example would move 13 to 12, but the second diagram has 14 vertices under its own assumptions. Neither diagram establishes the actual support requirements of a proposed fence.
Do not combine side results without a join record
Adding four separate straight-run post totals keeps all their endpoint entries. It does not decide which endpoints are the same location or whether the chosen system can share a support there. Blindly adding them, or blindly removing one post per corner, substitutes an assumption for a layout.
- Record each side length and the actual changes of direction.
- Identify each join by location so shared entries can be distinguished from separate supports.
- Keep openings, gate positions and their selected support details separate from a simple corner diagram.
- Use the chosen system's layout information to determine physical components; this tool cannot validate that relationship.
This page adds no multi-run or closed-layout feature. For the existing result, see how posts are counted. For the broader boundary, read what a single-run estimate covers.
Method and source
The straight-run output was checked against this site's unchanged calculation code and form. The two diagrams, endpoint-list sums and deduplication are independently derived hypothetical arithmetic. No real site measurements, manufacturer dimensions, construction standards or material prices were assumed. These are model comparisons, not a parts order or installation advice.