Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument mechanism / verified-clean

Hamming Distance / Error-Detection Calculator mechanism

The inspectable method record for Hamming Distance / Error-Detection Calculator, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

Model scope

The Hamming-distance computation is mathematically sound under equal-length, symbol-wise comparison. The instrument needs a defined code minimum-distance input or an explicit disclaimer that detection/correction figures are only pairwise-distance-based estimates, not guaranteed code capabilities. It also needs an explicit indexing convention, input validation, and an honest label because the current honest_label is empty.

  • The Hamming-distance formula is correct for equal-length sequences over an equality-comparable alphabet: d_H(x,y)=Σ_i [x_i≠y_i].
  • The detection and correction formulas are standard only when d denotes the minimum distance of an entire code, not merely the distance between the two input strings. With only two strings provided, the instrument cannot establish that the computed pairwise distance is the code minimum distance.
  • The specification does not state whether differing positions are reported using 0-based or 1-based indexing.
  • Equal-length validation is required; the formula is undefined for unequal-length inputs under the stated instrument definition.

Units and conventions

  • Hamming distance and error counts are dimensionless integer counts of symbol positions.
  • Binary inputs compare individual bits; text inputs compare individual symbols or code points for equality.
  • Test vectors assume differing positions are reported using 1-based indexing.
  • For detection and correction capability, d must be the minimum distance of a code, and errors are assumed to be symbol-position errors under the usual Hamming metric.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "x": "0000",
    "y": "0001"
  },
  "expected_outputs": {
    "hamming_distance": 1,
    "differing_positions": [
      4
    ],
    "detects_up_to_errors": 0,
    "corrects_up_to_errors": 0
  },
  "working": "Compare positions: 1: 0=0, no difference; 2: 0=0, no difference; 3: 0=0, no difference; 4: 0≠1, one difference. Therefore d=0+0+0+1=1. Detection: d−1=1−1=0. Correction: floor((d−1)/2)=floor(0/2)=0."
}

Failure boundary

  • Unequal-length inputs must be rejected before comparison; silently truncating, padding, or comparing only the overlapping prefix would produce an invalid result.
  • The detection and correction capabilities are not validly determined from an arbitrary pairwise distance unless that distance is known to be the code's minimum distance.
  • For d=0, the raw formulas produce −1 for both capabilities, which is not a meaningful error-detection or correction guarantee; capability outputs need a validity constraint such as d≥1 and a defined code minimum distance.
  • Text handling is ambiguous for Unicode strings: code units, code points, and user-perceived characters can yield different lengths and distances.
  • Empty strings produce distance 0 and require explicit handling.
  • No division-by-zero hazard exists in the stated formulas.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • VERIFIED_LEDGER.json
  • evidence-tranche4/tranche4-results.json