本文介绍如何在 Polars 中为每个 Date1 值，计算满足 Date2 ≤ Date1 ≤ Date3 条件的所有行的 Value 列之和（非传统顺序累积，而是“条件匹配求和”），并提供高效、可读的表达式方案及注意事项。
本文介绍如何在 polars 中为每个 `date1` 值，计算满足 `date2 ≤ date1 ≤ date3` 条件的所有行的 `value` 列之和（非传统顺序累积，而是“条件匹配求和”），并提供高效、可读的表达式方案及注意事项。
在 Polars 中实现“对每个日期查找其覆盖范围内的值并求和”，本质上属于自连接 + 过滤 + 聚合类操作。由于该逻辑依赖于当前行的 Date1 值动态筛选其他行（即“每行触发一次全局过滤”），无法直接通过 .group_by() 或 .cumsum() 等向量化聚合原语完成——因为条件中的 Date1 是变化的标量，而非分组键或排序依据。
最直观且可靠的实现方式是使用 map_elements 配合闭包内查询，如下所示：
result = (
testDf
.with_columns(
pl.col("Date1")
.map_elements(
lambda x: (
testDf.filter(
pl.col("Date2") <= x,
pl.col("Date3") >= x
)
.get_column("Value")
.sum()
),
return_dtype=pl.Int64
)
.alias("Sum")
)
.select(["Date1", "Sum"])
)执行后输出符合预期：
shape: (5, 2) ┌────────────┬─────┐ │ Date1 ┆ Sum │ │ --- ┆ --- │ │ date ┆ i64 │ ╞════════════╪═════╡ │ 2024-04-01 ┆ 0 │ │ 2024-04-06 ┆ 10 │ │ 2024-04-07 ┆ 25 │ │ 2024-04-10 ┆ -15 │ │ 2024-04-11 ┆ 5 │ └────────────┴─────┘
✅ 关键说明：
- map_elements 在此处是合理选择——它允许将每行 Date1 作为标量传入 Python 函数，在函数体内完成一次独立的 filter(...).sum() 查询；
- 尽管官方文档标注 map_elements “discouraged for performance”，但本例中数据规模适中（≤ 数万行）、逻辑清晰、易于维护，且无更优的纯表达式替代方案；
- 若数据量极大（如百万级），建议改用 显式自连接 + 条件 join 方式提升性能：
# 高性能替代方案（推荐用于大数据集）
joined = (
testDf.select(pl.col("Date1").alias("anchor_date"))
.join(
testDf.select(["Date2", "Date3", "Value"]),
left_on=[],
right_on=[],
how="cross"
)
.filter(pl.col("Date2") <= pl.col("anchor_date"),
pl.col("Date3") >= pl.col("anchor_date"))
.group_by("anchor_date")
.agg(pl.col("Value").sum().alias("Sum"))
.rename({"anchor_date": "Date1"})
)⚠️ 注意事项：
- map_elements 会禁用 Polars 的查询优化器（如 predicate pushdown），因此务必确保 testDf 已完成必要预处理（如列类型转换、索引准备）；
- 避免在 map_elements 内部重复调用 .collect() 或进行 I/O 操作；
- 如需进一步扩展（例如同时计算均值、计数），可在同一 filter 后链式调用 .agg() 多个聚合；
- 所有日期列必须为 pl.Date 类型（如示例中已用 .cast(pl.Date) 显式转换），否则比较操作可能失效或结果异常。
综上，该问题虽名为“条件累积和”，实为“逐点条件聚合”，应优先采用 map_elements 实现逻辑正确性，再根据数据规模决定是否升级为 cross join 优化方案。
