With Atcoder API of Lazy Segment Tree, Lazy Seg Tree Template
I am trying the problem where we need to support query to increment a range with a given value.
The Atcoder API implementation seems to fail here, where I have an array.
[3, 2, 4, 5, 1, 1, 5, 3]
and I want to do a range update over the range [1,4] ( 0 based indexing) and add a value 1 to it.
The sum should ideally change to 16 after the update and the array should look like
[3, 3, 5, 6, 2, 1, 5, 3]
The query function , the .prod() function of Atcoder API seems to return result 15,
You can try running this code for your reference to understand the ambiguity happening here.
I am using CPP20 and I am pretty sure (almost 99%) that it is a bug in their implementation,
just want someone to acknowledge it or maybe tell what am I missing here.
cc yosupo
UPD -> It is resolved but yeah things are kinda confusing with this template.
UPD 2-> This template is quite useful if you ever gone through the Polynomial queries question in CSES section about adding AP to a range . It is one among the toughest ones.
Here is the complete structure to AC it using AtCoder Template.
It is not a bug in their implementation. When you apply a range increment of $$$x$$$ to a segment, that segment's sum should increase by the segment's length multiplied by $$$x$$$, whereas your "mapping" function just increases said sum by $$$x$$$.
You must maintain the length of the segment in the node of segtree to execute Range Sum & Range Add Queries.
Your mapping should be {s,length} -> {s+f.x*length,length} instead of {s} -> {s+f.x}, because mapping should update all of the values in the range simultaneously.
Here is an example implementation.
Ahh I get your point but , How is it possible that when I print individual elements they are an exact same which is intended but with the prod function it seems to fail ? It’s super confusing
Lazy propagation itself is correct so each value for $$$[i,i+1)$$$ (single element) are collect if you access them, but $$$[i,j) (j \neq i+1)$$$ are incollect so the answers of range queries are wrong.
Ok I see, the examples link you have shared helps, Thanks physics0523
Auto comment: topic has been updated by KnightKnight (previous revision, new revision, compare).