Provides a reusable property-based test template for verifying the inverse property of numeric types under floating-point arithmetic.

Expresses the expectation that multiplying a number by its floating-point reciprocal yields a value close to one, documenting a numeric correctness expectation for testing frameworks.

When writing property-based tests for numeric algorithms, especially to verify floating-point inverse behavior, or when teaching floating-point rounding concepts.

Property-based testing with hypothesis, numerical analysis courses, floating-point verification suites, educational demonstrations of rounding error.

@given(st.integers()) def test_<name>(x): assume(x != 0); assert math.isclose(1/x * x, 1)

@given(st.integers()) def test_<name>(x): assume(x != 0); assert math.isclose(1/x * x, 1)

name: identifier for test function; strategy: hypothesis strategy for input generation (default st.integers()); assumption: boolean condition to exclude invalid inputs (default x != 0); assertion: expression to test (default math.isclose(1/x * x, 1))

• hypothesis
• given
• assume
• math.isclose
• property-based testing
• floating-point
• inverse property

• different numeric types (floats
• decimals
• numpy arrays)
• alternative assertions (math.isclose with explicit rel_tol/abs_tol
• numpy.allclose)
• alternative assumptions (x != 0 and not math.isinf(x))
• alternative operations (x * (1/x)
• x / x)

Forgetting to exclude zero leads to ZeroDivisionError; using exact equality (==) instead of math.isclose causes false failures due to rounding; using integer division in Python 2 yields zero; ignoring overflow or infinities produces infinite results; assuming exact equality for subnormal numbers.

testing additive inverse (x + (-x) == 0) – checks inverse under addition; testing multiplicative identity (x * 1 == x) – checks identity property; using exact equality for integer inverse – only valid in exact arithmetic.

Coming from mathematics: expecting exact equality may cause confusion about floating-point rounding → use tolerance-based comparison; Coming from languages with exact rational arithmetic (e.g., Ruby's Rational): assuming exact results → use appropriate tolerance or exact types.

• property-based testing
• floating-point robustness
• numeric invariants

(1) Do not use when exact integer arithmetic suffices and floating-point rounding is irrelevant; (2) Property-based testing can be slow due to many generated examples; consider limiting example count or using targeted strategies; (3) Edge cases like subnormal numbers, overflow to infinity, and NaN require separate handling as they violate the inverse property.

Provides confidence that floating-point implementations respect the approximate inverse property, helping catch subtle rounding bugs in numerical code before deployment.

Think of flipping a number upside down and flipping it back: you should see the same number, allowing for a tiny wobble due to floating-point fuzz.

This pattern relies on hypothesis' assumption to filter invalid inputs and math.isclose to tolerate floating-point error; adjust tolerance as needed for specific numeric ranges.

Progress to testing edge cases like infinities, NaNs, and subnormals, or use vectorized assertions with numpy.testing.assert_allclose for array inputs.