Our calculation standard
Each calculator starts with a defined question, the smallest useful set of inputs and a formula that can be explained in ordinary language. Results now carry a plain-language type label so users can distinguish a direct geometry calculation from a theoretical drivetrain calculation, a planning estimate or an empirical performance shortcut.
Result types
- Geometry calculation: a direct mathematical relationship based on dimensions you enter, such as tire diameter, wheel position, displacement or static compression geometry.
- Theoretical calculation: a mechanically correct relationship that can differ from measured road behavior because of slip, deflection or measurement error, such as RPM versus road speed.
- Direct ratio or cost estimate: arithmetic based on the values entered, where uncertainty mainly comes from the inputs, such as fuel cost or power-to-weight.
- Planning estimate: a useful sizing shortcut that must be verified against manufacturer data and operating conditions, such as injector flow.
- Empirical estimate: a relationship derived from observed performance patterns rather than a full physical simulation, such as the quarter-mile estimator.
Units and conversions
GarageMath keeps conversions explicit. The site uses the international inch definition of exactly 25.4 millimeters and 16.387064 cubic centimeters per cubic inch for displacement conversions. Displayed results may be rounded for readability, but the calculation is performed before display rounding.
Validation and test cases
Core equations live in a shared calculation module so the same math is used by the interface and automated tests. Known-answer tests cover tire diameter, wheel position, backspacing, gearing, fuel cost, power-to-weight, displacement, compression ratio, injector flow and quarter-mile estimates. Pull requests also run JavaScript syntax checks and the calculation test suite before changes are merged.
Worked examples and live substitution
Major tools include a worked example and the calculator result itself now shows the equation with the visitor's entered numbers substituted into it. This makes the math auditable without forcing the user to translate a generic formula mentally.
What GarageMath will not claim
A calculator cannot see a suspension arm, measure a real tire, verify a fuel pump, predict traction or inspect an engine. GarageMath separates calculated geometry from real-world fitment and planning estimates from verified specifications. Safety-critical or purchase-critical decisions should be checked against manufacturer data and physical measurements.
Source standard
GarageMath prefers primary or technically authoritative references for definitions and conversion factors, and manufacturer data for product-specific limits. Sources are selected to support the assumption being discussed rather than to decorate a page with links.
Reference starting points
- NIST: SI Units – Length for the exact inch-to-millimeter relationship.
- Michelin: Choosing the Right Tire Size for tire-size terminology and vehicle-specification guidance.
- DeatschWerks Fuel Injector Calculator as a manufacturer reference for injector planning inputs such as BSFC and duty cycle.
Connected measurement workflows
The Wheel & Tire Setup Planner combines existing tire and wheel geometry formulas in one comparison. Optional measured clearances use the current wheel edge as the baseline; they do not model the tire envelope or certify fitment. Tire results now include nominal dimensions in inches and millimeters, revolutions per mile and speed readings. Gearing tables compare final drives under the same assumptions, and fuel scenarios hold distance and price fixed while varying MPG.
New guides connect those calculations to measurement sheets and product-verification steps. All diagrams, examples, prose and implementation are authored for GarageMath. Results remain mathematical comparisons rather than vehicle-specific approvals.
October 2026 maintenance
The calculator pages now include additional comparison scenarios and measurement checks, including overbore displacement, a compression-volume budget and injector sizing across multiple assumptions. Input checks reject missing or non-finite numbers, zero denominators and fractional cylinder or injector counts. Search metadata and sitemaps use the final page addresses served by the site.
Input labels and reference conventions
Nominal means derived from a designation or simplified dimension. Published means a stated product specification under its documented conditions. Measured means a physical observation with a method and condition. Estimated means a model result that depends on assumptions. These labels are not interchangeable claims of accuracy.
Wheel comparisons use bead-seat width and signed offset. Physical edge changes assume comparable flange allowances; actual lip-to-pad backspacing requires its own data. Geometric tire circumference is not measured rolling circumference. Compression is per cylinder and uses the sign conventions stated on the tool.
What the automated checks establish
The test suite checks known numerical answers, rejection of missing and non-finite inputs, integer counts, metric and inch tire formats, unit conversion, optional comparisons and initialization of all eleven calculator pages. Structure checks cover local links, anchors, canonical addresses, sitemap targets and structured-data syntax. These checks detect specific regressions; they do not validate a vehicle fitment or certify every technical statement.
Worked examples are checked against the shared module and recorded reference calculations. Browser checks assess selected interactions and presentation. Device and assistive-technology coverage is reported only where actually checked, rather than inferred from responsive CSS.
Editorial sourcing and AI assistance
Drafting and development may use AI assistance. A generated statement is not a source. Definitions and limits should be checked against the relevant standard, manufacturer or authoritative reference; product applicability must come from the exact documentation. John owns the project and correction channel. The process does not imply that an independent human technical specialist has reviewed every claim.
Diagnostic reference boundary
An OBD2 lookup has not been launched. Before diagnostic content is added, its definition source, reuse rights, edition, applicability and verification record must be established. A code records a monitoring result; it does not prove a failed part. Possible causes will not be ranked without supporting evidence, and reference material will remain distinct from diagnosis.
Dates and maintenance
A substantive update date records changed content. A calculation-check date records arithmetic verification. Neither implies fresh physical testing of a vehicle or product. Source or implementation changes trigger the relevant review; a correction report can also trigger a review. Search metadata should match substantive content updates rather than being refreshed merely to appear current.
Corrections
If a result appears wrong, use the Report issue action on a calculator or email [email protected]. Include the page, input values, observed result and expected result. Reproducible math errors are treated as defects; unclear assumptions are treated as documentation defects.
Methodology version 3.6 · updated October 9, 2026