Concept for a linear operator's shape/apply contract under a given backend: domain_size, range_size, and apply(x, y). An operator may additionally provide apply(x, y, workspace) and/or a scaled-apply apply(alpha, x, beta, y) member, but neither is required by this concept – both degrade gracefully (see impl::make_workspace and HasScaledApplyMember below). More...

#include <solver_backends.hpp>

Concept definition

template<class Backend, class Op, class XVector, class YVector>
concept LinearOperator =
    requires(const Op& op, const XVector& x, YVector& y) {
      { Backend::domain_size(op) } -> std::convertible_to<size_t>;
      { Backend::range_size(op) } -> std::convertible_to<size_t>;
      { Backend::apply(op, x, y) } -> std::same_as<void>;
    } && (impl::DenseMatView<Op> || is_matrix_v<Op> || impl::HasApplyMember<Op, XVector, YVector> ||
          impl::HasApplyMemberWithWorkspace<Op, XVector, YVector, impl::workspace_for_t<Op>>)

Detailed Description

Both KokkosBackend and MundyMathBackend dispatch Backend::domain_size/range_size/apply to a MUNDY_THROW_REQUIRE-at-runtime fallback for any Op that isn't otherwise recognized, so those three expressions alone are well-formed (and thus satisfied) for literally any Op – checking only them would make this concept accept non-operators. The additional clause below requires Op to actually be one of the shapes a backend can recognize (a dense matrix/view, or a type that provides its own apply member), so a type with none of those is correctly rejected instead of silently passing and only failing at runtime.