信息合并：where 结合律 from？

在构造历史和相关问题的信息合并时，我们通常会发现已构造信息的合并不够封闭，所以我们增加新的信息直到它封闭。

而对于另一类问题，我们有可能会发现：信息是可以合并的，但是这玩意没有结合律，我们就无法用已有的强大数据结构来维护了。

本文论述了一个策略：我们不应在思考信息合并相关问题时做出“某信息的合并没有结合律”这样的武断。

信息是否具有结合律，与合并的形式密切相关，或者说，我们把原始信息针对合并这个问题进行了一定的优秀包装，使其拥有了结合律。

如果我们只盯着原始信息是否具有结合律，就极易走入歧途，从而可能“剪枝”掉某个问题的正确做法。

下面以两个例子抛砖引玉。

在 2024/11/29 的 Universal OJ 用户群聊天记录中，有人提出了一个问题：给出若干个三维向量，单点修改，多次区间查询 $v_l\times (v_{l+1}\times(\cdots\times (v_{r-1}\times v_r)))$，其中 $(x,y,z)_1\times (x,y,z)_2=(y_1z_2-y_2z_1,z_1x_2-z_2x_1,x_1y_2-x_2y_1)$。

容易验证叉积没有结合律。

但我们发现，$u\times v$ 可以看作一个向量对另一个向量的线性变换，所以我们当然可以将其写成矩阵的形式，设 $M(a)$ 是满足 $a\times b=M(a)b$ 的矩阵，则我们直接求出 $\prod_{i=l}^{r-1}M(v_i)\times v_r$ 即可。

从另一个角度看，如果我们算 $a\times(b\times c)$ 时先算出 $a\times b$，这是错误地把 $a,b$ 看成和 $c$ 等同的地位了，当计算方向是从右往左时，我们应该将 $b\times c$ 看作“$b$ 对 $c$ 的操作”，而我们要做的事更像是 操作之间的合并，而非所谓的信息合并。

一个思考方式：操作的合并很类似于懒标记的合并。

下文称 在楼房重建一题广泛使用的单侧递归线段树/平衡树 为楼房重建树。

我们都知道前缀最大值的个数可以记录最大值实现 $\mathcal O(1)$ 的 push_back，但是“该信息并没有结合律”。

通俗的讲我们有 struct node{int mx,sum;} 和 node operator+(node a,int b) 之后，无法实现 node operator+(node a,node b)，这是大多数信息无法合并的困局所在。

同样的，我们考虑将 $a(\text{node})+b(\text{int})$ 看作 $b$ 对 $a$ 的操作，则我们要考虑的是 操作之间的合并。

不难发现，对于一连串的操作我们也只关心其前缀最大值，我们需要支持对操作序列进行二分，求出后缀（有效部分）的和，但我们不方便带着一坨序列移动，所以我们利用可持久化树存下这个过程即可完成信息的合并。

我们自然地推导出了楼房重建的 树套可持久化平衡树 的做法。