Equipment Data Acceptance: Explain Numerical Closeness

Numerical closeness in a software comparison is a rule that needs explanation. It is not automatically the acceptance limit for a measuring instrument or a smart-equipment delivery. A supplier might include a comparison script in a data handover, and a buyer needs to understand what its result means before adopting it. This checklist considers that proposed review. It runs no calculation, inspects no instrument, and supplies no numerical acceptance limits.

Name the question the comparison is meant to answer

Ask why the supplier compares the two values. The task might concern consistency between exported representations, agreement with a stated reference, or another documented data check. These purposes should be named separately from a decision about the equipment’s suitability.

The receiving reviewer needs the roles of both inputs. A value observed in an actual measurement and a value expected by a program are not interchangeable descriptions. The handover should explain their origins without relabeling a software expectation as an independently established measurement reference.

For the fictional review, keep both inputs unspecified. Inventing realistic-looking readings would add no evidence. Instead, prepare a question asking the supplier which actual values were compared and what transformation, if any, occurred before comparison. That creates a useful place for real evidence when it becomes available.

Identify the exact tolerance rule

The Python math documentation defines math.isclose using relative and absolute tolerances. Its relative comparison uses the larger absolute magnitude of the two inputs. The acceptance note should identify the actual function and configuration rather than summarize the result as approximately equal.

This matters because the word tolerance can refer to different things in engineering and software. A numerical threshold selected for a computation is not, simply by having that name, a specification tolerance or an uncertainty evaluation. Ask the supplier to explain the intended relationship instead of assuming equivalence.

The documented near-zero case also deserves attention. The Python reference explains why an absolute tolerance may be needed when comparing with zero. The buyer should ask how the actual comparison handles that context rather than assume a relative setting expresses every relevant requirement.

Do not transfer conventions between libraries silently

NumPy’s isclose documentation describes a different comparison convention: the second argument is treated as the reference in the relative term, and the operation is not generally symmetric in its two arguments. The names of the functions are not enough to make their results interchangeable.

If a supplier changes the implementation, request a description of the comparison convention and input order. A receiver should not conclude that the same method was retained merely because the replacement function has a similar name. The relevant behavior needs to remain visible in the review record.

No example values are calculated here. The point is to ask which documented rule the delivered implementation uses. An actual comparison would need its own inputs, settings, environment, and observed output. A quotation from a library manual cannot stand in for that execution record.

Connect the rule to its intended decision without conflating them

The supplier should explain why the chosen comparison is appropriate for the stated data task. A receiver can then ask whether that task answers the contractual question being considered. If the relationship is missing, the numerical result should remain a limited software observation.

For example, consistency between two exports would not alone establish instrument accuracy, repeatability, or suitability near a specification boundary. Those claims have their own evidence requirements. The checklist should not broaden an arithmetic test into an equipment performance certificate.

Keep unresolved matters explicit. If the tolerance setting has no documented rationale, request one. If the input roles are unclear, ask for their definitions. Choosing settings after seeing which result looks desirable would obscure the acceptance question rather than resolve it.

Require a reviewable account of later changes

A revised script, a changed reference convention, or a different input conversion can affect interpretation even when the visible report retains the same success wording. Ask the supplier which part changed and which checks were repeated. Preserve the earlier record with its original scope.

The final handover should let another reader distinguish the data comparison, the tolerance rule, the actual observation, and the separate equipment decision. This article proposes those review questions; it reports no tested script, approved supplier, or completed instrument acceptance.

More explanations appear in our equipment information section and the reading directory. The original illustrations contain no readings, limits, uncertainty budgets, calculated differences, or pass rates. They organize the reasoning a real reviewer would need to examine.