Skip to content

arena: support permuted Hadamard add/subt/mult on Tensor<ArenaTensor> ToT#555

Open
evaleev wants to merge 1 commit into
masterfrom
evaleev/fix/arena-tot-permuted-binary-ops
Open

arena: support permuted Hadamard add/subt/mult on Tensor<ArenaTensor> ToT#555
evaleev wants to merge 1 commit into
masterfrom
evaleev/fix/arena-tot-permuted-binary-ops

Conversation

@evaleev
Copy link
Copy Markdown
Member

@evaleev evaleev commented May 23, 2026

Problem

The permuted, arena ToT × arena ToT overloads of add, subt, and mult (scaled and unscaled) on TA::Tensor<ArenaTensor> threw "permuted ... of a tensor-of-tensors is not yet supported". This blocks CSV/PNO-based coupled-cluster in MPQC, whose residual evaluates permuted ToT Hadamard products at the tile-op level (the binary Mult/Add tile op calls left.mult(right, perm) directly).

Fix

By the time a permuted product reaches a tile op, the expression engine has already brought both operands to a common (congruent) layout, so the elementwise product/sum is valid and perm is purely the result permutation. Compute the unpermuted result, then apply perm as a post-pass via permute(), which already handles arena ToT — a shallow outer-cell reindex (arena_permute_shallow) plus an inner-slab rewrite (arena_inner_permute) when the bipartite permutation's inner part is non-trivial. This mirrors the existing numeric × arena permuted-mult branches.

Covers all six overloads that shared the stub: add(perm), add(factor,perm), subt(perm), subt(factor,perm), mult(perm), mult(factor,perm).

Validation

A previously-failing MPQC PNO-CCSD job (H₂O/cc-pVDZ, PaoPnoRMP2CCk) now runs to convergence (13 iterations, E = −76.23928119138472) with no exception.

… ToT

The permuted, arena ToT x arena ToT overloads of add, subt, and mult
(scaled and unscaled) previously threw "permuted ... of a
tensor-of-tensors is not yet supported". This blocked CSV/PNO-based
coupled-cluster, whose residual evaluates permuted ToT Hadamard
products at the tile-op level (a binary Mult/Add op calling
left.mult(right, perm) etc.).

By the time a permuted product reaches a tile op, the expression engine
has already brought both operands to a common (congruent) layout, so the
elementwise product/sum is valid and perm is purely the result
permutation. Compute the unpermuted result, then apply perm as a
post-pass via permute(), which already handles arena ToT: a shallow
outer-cell reindex (arena_permute_shallow) plus an inner-slab rewrite
(arena_inner_permute) when the bipartite permutation's inner part is
non-trivial. This mirrors the existing numeric x arena permuted-mult
branches.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant