ExplicitEquality
================

.. toctree::
   :hidden:

   /autoapi/t3toolbox/backend/common/ExplicitEquality.__eq__

.. py: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.


   .. py:attribute:: __hash__
      :value: None


Methods
-------

.. autoapisummary::

   t3toolbox.backend.common.ExplicitEquality.__eq__