Small golf and memory reduction in segment tree

[Mukundan314]

Is there any reason why the initial implementation rounded up to the nearest power of 2?

[bjorn-martinsson]

Power of 2 sized segment trees are a lot easier to binary search through (the technique where you start at the top and walk down to a leaf). If the segment tree doesn't have a power of 2 in size, then it effectively consists of log n many power of 2 sized segment trees, meaning you'd have log n possible starting positions for the binary search. So that is one reason.

Another reason is that power of 2 sized segment trees are easier to understand. If the segment tree is not a power of two, then you can still decompose it into log n power of 2 segment trees. So from a beginners perspective, power of 2 sized segment trees are much simpler to learn and understand.

Another drawback is that power of 2 sized segment trees are easier to "build" (populating the .data variable). You can still do it in the non-power of 2 case, but it is more messy.

There are some pros with allowing non-power of 2 sized segment trees. Less code (unless you are trying to binary search), less memory usage, probably slightly faster. Another pro is that you don't need any padding.

[Mukundan314]

Yeah, I didn't think about the use case of searching for nodes from the root. I think the advantages of a non-power of 2 sized segment tree are very small compared to the ability to implement a simpler binary search.

[bjorn-martinsson]

It depends on what you want. If you want to explain segment trees to someone, you would 100% go with the power of 2 version. But if you just want a black box segment tree, then you should go for the non-power of 2. In my opinion, I think the power of 2 version is better to have in a coding library because there are so many problems out there that force you to modify the segment tree.

[Mukundan314]

tbh I usually switch to C++ when I need a modified segment tree (and just implement it from scratch). For modified lazy segment trees, I always end up switching since I find the LazySegmentTree implementation here quite difficult to modify.

[bjorn-martinsson]

I think recursive segment trees are easier to work with in general. Techniques like persistence or segtree beats basically require the recursive version.

Maybe it could be a good idea to add some kind of recursive version to pyrival? I wonder how much slower that would be.