ExplicitEquality#

class t3toolbox.backend.common.ExplicitEquality#

Mixin making == a directed error and the class unhashable: equality must be EXPLICIT.

The library’s equality rule (ruled 2026-08-24, review R1-13 extended): hash/eq belongs to the jit-cache-key objects only (the aux_data family – mask holders, geometries, sampling kinds – which hash by VALUE because their equality decides compiled-program reuse). Every runtime array-carrying class (trains, weights, frames, variations, tangents) instead REFUSES ==: the arithmetic dunders act on the represented mathematical objects, but Python’s == carries container/hashing/bool obligations no float-representation equality can honestly satisfy – exact mathematical equality is not a well-posed float predicate for implicit representations (two representations of the same tensor differ in the last ulp), and a tolerance-based == is not an equivalence relation. So the user says which equality they mean:

  • a.allclose(b[, rtol=, atol=]) – numerical equality of what the objects REPRESENT (per stack element; for frames: the base point, with safety.frames_equal answering the same-FRAME question);

  • a.corewise_equal(b) – bitwise equality of the stored representation;

  • a is b – object identity (x == x is True via the identity fast path).

Consequences: instances are unhashable (no dict keys / sets – key by id(obj) and keep the object alive, as for numpy arrays), and x in list works only up to the first non- identical element (Python’s containment calls ==). Subclasses must be @dataclass(frozen=True, eq=False) so this __eq__ stands.

__hash__ = None#

Methods#

__eq__(other)