2 Segment trees

Figure 7 exhibits a simple implementation of a segment tree in Haskell, using some utilities for working with index ranges shown in Figure 8. We store a segment tree as a recursive algebraic data type and implement update and rq using code that directly corresponds to the recursive descriptions given in the previous section; get and set can then also be implemented in terms of them. It is not hard to generalize this code to work for segment trees storing values from either an arbitrary commutative monoid if we don’t need the set operation—or from an arbitrary Abelian group (i.e. commutative monoid with inverses) if we do need set—but we keep things simple since the generalization doesn’t add anything to our story.

Fig. 7

Simple segment tree implementation in Haskell.

Fig. 8

Range utilities.

Although this implementation is simple and relatively straightforward to understand, compared to simply storing the sequence of values in an array, it incurs a good deal of overhead. We can be more clever in our use of space by storing all the nodes of a segment tree in an array, using the standard left-to-right breadth-first indexing scheme illustrated in Figure 9 (for example, this scheme, or something like it, is commonly used to implement binary heaps). The root has label 1; every time we descend one level we append an extra bit: 0 when we descend to the left child and 1 when we descend to the right. Thus, the index of each node expressed in binary records the sequence of left-right choices along the path to that node from the root. Going from a node to its children is as simple as doing a left bit shift and optionally adding 1; going from a node to its parent is a right bit shift. This defines a bijection from the positive natural numbers to the nodes of an infinite binary tree. If we label the segment tree array with $s_1 \ldots s_{2n-1}$ , then $s_1$ stores the sum of all the $a_i$ , $s_2$ stores the sum of the first half of the $a_i$ , $s_3$ stores the sum of the second half, and so on. $a_1 \ldots a_n$ themselves are stored as $s_n \ldots s_{2n-1}$ .

Fig. 9

Indexing a binary tree.

The important point is that since descending recursively through the tree corresponds to simple operations on indices, all the algorithms we have discussed can be straightforwardly transformed into code that works with a (mutable) array: for example, instead of storing a reference to the current subtree, we store an integer index; every time we want to descend to the left or right, we simply double the current index or double and add one, and so on. Working with tree nodes stored in an array presents an additional opportunity: rather than being forced to start at the root and recurse downwards, we can start at a particular index of interest and move up the tree instead.

So how do we get from segment trees to Fenwick trees? We start with an innocuous-seeming observation: not all the values stored in a segment tree are necessary. Of course, all the non-leaf nodes are “unnecessary” in the sense that they represent cached range sums which could easily be recomputed from the original sequence. That’s the whole point: caching these “redundant” sums trades off space for time, allowing us to perform arbitrary updates and range queries quickly, at the cost of doubling the required storage space.

But that’s not what I mean! In fact, there is a different set of values we can forget about, but in such a way that we still retain the logarithmic running time for updates and range queries. Which values, you ask? Simple: just forget the data stored in every node which is a right child. Figure 10 shows the same example tree we have been using, but with the data deleted from every right child. Note that “every right child” includes both leaves and internal nodes: we forget the data associated to every node which is the right child of its parent. We will refer to the nodes with discarded data as inactive and the remaining nodes (that is, left children and the root) as active. We also say that a tree with all its right children inactivated in this way has been thinned.

Fig. 10

Inactivating all right children in a segment tree.

Updating a thinned segment tree is easy: just update the same nodes as before, ignoring any updates to inactive nodes. But how do we answer range queries? It’s not too hard to see that there is enough information remaining to reconstruct the information that was discarded (you might like to try convincing yourself of this: can you deduce what values must go in the greyed-out nodes in Figure 10, without peeking at any previous figures?). However, in and of itself, this observation does not give us a nice algorithm for computing range sums.

It turns out the key is to think about prefix sums. As we saw in the introduction and the implementation of range in Figure 6, if we can compute the prefix sum $P_k = a_1 + \ldots + a_k$ for any k, then we can compute the range sum $a_i + \ldots + a_j$ as $P_j - P_{i-1}$ .

First, the root itself is active, and hence, querying the full range will work. Next, consider the case where we are at a node and recurse on both children. The left child is always active, so we only need to consider the case where we recurse to the right. It is impossible that the range of the right child will be wholly contained in the query range: since the query range is always a prefix of the form $[1,\ j]$ , if the right child’s range is wholly contained in $[1,\ j]$ then the left child’s range must be as well—which means that the parent node’s range (which is the union of its children’s ranges) would also be wholly contained in the query range. But in that case we would simply return the parent’s value without recursing into the right child. Thus, when we do recurse into a right child, we might end up returning 0, or we might recurse further into both grandchildren, but in any case we will never try to look at the value of the right child itself.

Figure 11 illustrates performing a prefix query on a segment tree. Notice that visited right children are only ever blue or grey; the only green nodes are left children.

Fig. 11

Performing a prefix query on a segment tree.

3 Fenwick trees

How should we actually store a thinned segment tree in memory? If we stare at Figure 10 again, one strategy suggests itself: simply take every active node and “slide” it down and to the right until it lands in an empty slot in the underlying array, as illustrated in Figure 12. This sets up a one-to-one correspondence between active nodes and indices in the range $1 \ldots n$ . Another way to understand this indexing scheme is to use a postorder traversal of the tree, skipping over inactive nodes and giving consecutive indices to active nodes encountered during the traversal. We can also visualize the result by drawing the tree in a “right-leaning” style (Figure 13), vertically aligning each active node with the array slot where it is stored.

Fig. 12

Sliding active values down a thinned segment tree.

Fig. 13

Right-leaning drawing of a thinned segment tree, vertically aligning nodes with their storage location.

This method of storing the active nodes from a thinned segment tree in an array is precisely a Fenwick tree. I will also sometimes refer to it as a Fenwick array, when I want to particularly emphasize the underlying array data structure. Although it is certainly a clever use of space, the big question is how to implement the update and range query operations. Our implementations of these operations for segment trees worked by recursively descending through the tree, either directly if the tree is stored as a recursive data structure, or using simple operations on indices if the tree is stored in an array. However, when storing the active nodes of a thinned tree in a Fenwick array, it is not a priori obvious what operations on array indices will correspond to moving around the tree. In order to attack this problem, we first take a detour through a domain-specific language for two’s complement binary values.

4 Two’s complement binary

The bit tricks usually employed to implement Fenwick trees rely on a two’s complement representation of binary numbers, which allow positive and negative numbers to be represented in a uniform way; for example, a value consisting of all 1 bits represents $-1$ . We therefore turn now to developing a domain-specific language, embedded in Haskell, for manipulating two’s complement binary representations.

First, we define a type of bits, with functions for inversion, logical conjunction, and logical disjunction:

Next, we must define bit strings, i.e. sequences of bits. Rather than fix a specific bit width, it will be much more elegant to work with infinite bit strings.Footnote ³ It is tempting to use standard Haskell lists to represent potentially infinite bit strings, but this leads to a number of problems. For example, equality of infinite lists is not decidable, and there is no way in general to convert from an infinite list of bits back to an Integer—how would we know when to stop? In fact, these practical problems stem from a more fundamental one: infinite lists of bits are actually a bad representation for two’s complement bit strings, because of “junk”, that is, infinite lists of bits which do not correspond to values in our intended semantic domain. For example, cycle [I,O] is an infinite list which alternates between I and O forever, but it does not represent a valid two’s complement encoding of an integer. Even worse are non-periodic lists, such as the one with I at every prime index and O everywhere else.

In fact, the bit strings we want are the eventually constant ones, that is, strings which eventually settle down to an infinite tail of all zeros (which represent nonnegative integers) or all ones (which represent negative integers). Every such string has a finite representation, so directly encoding eventually constant bit strings in Haskell not only gets rid of the junk but also leads to elegant, terminating algorithms for working with them.

Rep b represents an infinite sequence of bit b, whereas Snoc bs b represents the bit string bs followed by a final bit b. We use Snoc, rather than Cons, to match the way we usually write bit strings, with the least significant bit last. Note also the use of a strictness annotation on the Bits field of Snoc; this is to rule out infinite lists of bits using only Snoc, such as bs=Snoc (Snoc bs O) I. In other words, the only way to make a non-bottom value of type Bits is to have a finite sequence of Snoc finally terminated by Rep.

Although we have eliminated junk values, one remaining problem is that there can be multiple distinct representations of the same value. For example, Snoc (Rep O) O and Rep O both represent the infinite bit string containing all zeros. However, we can solve this with a carefully constructed bidirectional pattern synonym (Pickering et al., Reference Pickering, Érdi, Peyton Jones and Eisenberg2016).

Matching with the pattern ${({bs}\mathrel{:\!.}{b})}$ uses a view pattern (Erwig & Jones, Reference Erwig and Jones2001) to potentially expand a Rep one step into a Snoc, so that we can pretend Bits values are always constructed with ${(\mathrel{:\!.})}$ . Conversely, constructing a Bits with ${(\mathrel{:\!.})}$ will do nothing if we happen to snoc an identical bit b onto an existing ${{Rep}\;{b}}$ . This ensures that as long as we stick to using ${(\mathrel{:\!.})}$ and never directly use Snoc, Bits values will always be normalized so that the terminal ${{Rep}\;{b}}$ is immediately followed by a different bit. Finally, we mark the pattern ${(\mathrel{:\!.})}$ as COMPLETE on its own, since matching on ${(\mathrel{:\!.})}$ is indeed sufficient to handle every possible input of type Bits. However, in order to obtain terminating algorithms we will often include one or more special cases for Rep.

Let’s begin with some functions for converting Bits to and from Integer and for displaying Bits (intended only for testing).

Let’s try it out, using QuickCheck (Claessen & Hughes, Reference Claessen and Hughes2000) to verify our conversion functions:

We can now begin implementing some basic operations on Bits. First, incrementing and decrementing can be implemented recursively as follows:

The least significant bit, or LSB, of a sequence of bits can be defined as follows:

Note that we add a special case for ${{Rep}\;{O}}$ to ensure that lsb is total. Technically, ${{Rep}\;{O}}$ does not have a least significant bit, so defining ${{lsb}\;({Rep}\;{O})\mathrel{=}{Rep}\;{O}}$ seems sensible.

Bitwise logical conjunction can be defined straightforwardly. Note that we only need two cases; if the finite parts of the inputs have different lengths, matching with ${(\mathrel{:\!.})}$ will automatically expand the shorter one to match the longer one.

Bitwise inversion is likewise straightforward.

The above functions follow familiar patterns. We could easily generalize to eventually constant streams over an arbitrary element type and then implement in terms of a generic zipWith and inv in terms of map. However, for the present purpose we do not need the extra generality.

We implement addition with the usual carry-propagation algorithm, along with some special cases for Rep.

It is not too hard to convince ourselves that this definition of addition is terminating and yields correct results; but we can also be fairly confident by just trying it with QuickCheck:

Finally, the following definition of negation is probably familiar to anyone who has studied two’s complement arithmetic; I leave it as an exercise for the interested reader to prove that ${{x}\oplus{neg}\;{x}\equiv {Rep}\;{O}}$ for all ${{x}\mathbin{::}{Bits}}$ .

We now have the tools to resolve the first mystery of the Fenwick tree implementation.

Proof. By induction on x.

• • First, if ${{x}\mathrel{=}{Rep}\;{O}}$ , it is an easy calculation to verify that .

• • Likewise, if ${{x}\mathrel{=}{Rep}\;{I}}$ , both ${{lsb}\;{x}}$ and reduce to ${{Rep}\;{O}\mathrel{:\!.}{I}}$ .

• • If ${{x}\mathrel{=}{xs}\mathrel{:\!.}{O}}$ , then ${{lsb}\;{x}\mathrel{=}{lsb}\;({xs}\mathrel{:\!.}{O})\mathrel{=}{lsb}\;{xs}\mathrel{:\!.}{O}}$ by definition, whereas

  

• • Next, if ${{x}\mathrel{=}{xs}\mathrel{:\!.}{I}}$ , then ${{lsb}\;({xs}\mathrel{:\!.}{I})\mathrel{=}{Rep}\;{O}\mathrel{:\!.}{I}}$ by definition, whereas

For the last equality, we need a lemma that , which should be intuitively clear and can easily be proved by induction as well.

Finally, in order to express the index conversion functions we will develop in the next section, we need a few more things in our DSL. First, some functions to set and clear individual bits and to test whether particular bits are set:

The only other things we will need are left and right shift, and a generic while combinator that iterates a given function, returning the first iterate for which a predicate is false.

5 Index conversion

Before deriving our index conversion functions, we must deal with one slightly awkward fact. In a traditional binary tree indexing scheme, as shown in Figure 9, the root has index 1, every left child is twice its parent, and every right child is one more than twice its parent. Recall that in a thinned segment tree, the root node and every left child are active, with all right children being inactive. This makes the root an awkward special case—all active nodes have an even index, except the root, which has index 1. This makes it more difficult to check whether we are at an active node—it is not enough to simply look at the least significant bit.

One easy way to fix this is simply to give the root index 2 and then proceed to label the rest of the nodes using the same scheme—every left child is twice its parent, and every right child is one more than twice its parent. This results in the indexing shown in Figure 14, as if we had just taken the left subtree of the tree rooted at 1, and ignored the right subtree. Of course, this means about half the possible indices are omitted—but that’s not a problem, since we will only use these indices as an intermediate step which will eventually get fused away.

Fig. 14

Indexing a binary tree with 2 at the root.

Figure 15 shows a binary tree where nodes have been numbered in two different ways: the left side of each node shows the node’s binary tree index (with the root having index 2). The right side of each node shows its index in the Fenwick array, if it has one (inactive nodes simply have their right half greyed out). The table underneath shows the mapping from Fenwick array indices (top row) to binary tree indices (bottom row). As a larger example, Figure 16 shows the same thing on a binary tree one level deeper.

Fig. 15

Binary tree labelled with both binary and Fenwick indexing.

Fig. 16

Binary tree labelled with both binary and Fenwick indexing.

Our goal is to come up with a way to calculate the binary index for a given Fenwick index or vice versa. Staring at the table in Figure 16, a few patterns stand out. Of course, all the numbers in the bottom row are even, which is precisely because the binary tree is numbered in such a way that all active nodes have an even index. Second, we can see the even numbers $32, 34 \ldots 46$ , in order, in all the odd positions. These are exactly the leaves of the tree, and indeed, every other node in the Fenwick array will be a leaf from the original tree. Alternating with these, in the even positions, are the numbers $16\;\; 8\;\; 18\;\; 4 \ldots$ , which correspond to all the non-leaf nodes; but these are exactly the sequence of binary indices from the bottom row of the table in Figure 15—since the internal nodes in a tree of height 4 themselves constitute a tree of height 3, with the nodes occurring in the same order.

These observations lead to the recurrence shown in Figure 17 for the sequence $b_n$ of binary indices for the nodes stored in a Fenwick array of length $2^n$ : $b_0$ is just the singleton sequence [2], and otherwise $b_n$ is the even numbers $2^{n+1}, 2^{n+1} + 2, \ldots, 2^{n+1} + 2^n - 2$ interleaved with $b_{n-1}$ .

Fig. 17

Recurrence for sequence of binary tree indices in a Fenwick array.

We can check that this does in fact reproduce the observed sequence for $n = 4$ :

Let ${{s}\text{ ! }{k}}$ denote the kth item in the list s (counting from 1), as defined in Figure 18. The same figure also lists two easy lemmas about the interaction between indexing and interleaving, namely ${({xs}{\curlyvee}{ys})\text{ ! }(\mathrm{2}\cdot{j})\mathrel{=}{ys}\text{ ! }{j}}$ and ${({xs}{\curlyvee}{ys})\text{ ! }(\mathrm{2}\cdot{j}\mathbin{-}\mathrm{1})\mathrel{=}{xs}\text{ ! }{j}}$ (as long as xs and ys have equal lengths). With these in hand, we can define the Fenwick to binary index conversion function as

\[ {{f2b}\;{n}\;{k}\mathrel{=}{b}\;{n}\text{ ! }{k}}. \]

Of course, since $b_n$ is of length $2^n$ , this function is only defined on the range $[1, 2^n]$ .

Fig. 18

Indexing and interleaving.

We can now simplify the definition of f2b as follows. First of all, for even inputs, we have

And for odd inputs,

Thus, we have

\[ {{f2b}\;{n}\;{k}} = \begin{cases} {{f2b}\;({n}\mathbin{-}\mathrm{1})\;({k}\mathbin{/}\mathrm{2})} & k \text{ even} \\ 2^{n+1} + k - 1 & k \text{ odd} \end{cases} \]

Note that when $n = 0,$ we must have $k = 1$ , and hence, ${{f2b}\;\mathrm{0}\;\mathrm{1}} = 2^0 + 1 - 1 = 1$ , as required, so this definition is valid for all $n {\geqslant} 0$ . Now factor k uniquely as $2^a \cdot b$ where b is odd. Then by induction we can see that

\[ {{f2b}\;{n}\;(\mathrm{2}^ {{a}}\cdot{b})\mathrel{=}{f2b}\;({n}\mathbin{-}{a})\;{b}} = 2^{n-a+1} + b - 1. \]

So, in other words, computing f2b consists of repeatedly dividing by 2 (i.e. right bit shifts) as long as the input is even and then finally decrementing and adding a power of 2. However, knowing what power of 2 to add at the end depends on knowing how many times we shifted. A better way to think of it is to add $2^{n+1}$ at the beginning, and then let it be shifted along with everything else. Thus, we have the following definition of f2b’ using our Bits DSL. Defining ${{shift}\;{n}\mathrel{=}{while}\;{even}\;{shr}\mathbin{\circ}{set}\;{n}}$ separately will make some of our proofs more compact later.

For example, we can verify that this produces identical results to ${{f2b}\;\mathrm{4}}$ on the range $[1, 2^4]$ (for convenience, we define ${({f}\mathbin{===}{g})\;{k}\mathrel{=}{f}\;{k}\equiv {g}\;{k}}$ ):

We now turn to deriving ${{b2f}\;{n}}$ , which converts back from binary to Fenwick indices. ${{b2f}\;{n}}$ should be a left inverse to ${{f2b}\;{n}}$ , that is, for any $k \in [1, 2^n]$ we should have ${{b2f}\;{n}\;({f2b}\;{n}\;{k})\equiv {k}}$ . If k is an input to ${{f2b}}$ , we have $k = 2^a \cdot b {\leqslant} 2^n$ , and so $b-1 < 2^{n-a}$ . Hence, given the output ${{f2b}\;{n}\;{k}} = m = 2^{n-a+1} + b - 1$ , the highest bit of m is $2^{n-a+1}$ , and the rest of the bits represent $b-1$ . So, in general, given some m which is the output of ${{f2b}\;{n}}$ , we can write it uniquely as $m = 2^c + d$ where $d < 2^{c-1}$ ; then

\[ {{b2f}\;{n}\;(\mathrm{2}^ {{c}}\mathbin{+}{d})\mathrel{=}\mathrm{2}^ {{n}\mathbin{-}{c}\mathbin{+}\mathrm{1}}\cdot({d}\mathbin{+}\mathrm{1})}. \]

In other words, given the input $2^c + d$ , we subtract off the highest bit $2^c$ , increment, then left shift $n-c+1$ times. Again, though, there is a simpler way: we can increment first (note since $d < 2^{c-1}$ , incrementing cannot disturb the bit at $2^c$ ), then left shift enough times to bring the leftmost bit into position $n+1$ , and finally remove it. That is:

Verifying:

6 Deriving Fenwick operations

We can now finally derive the required operations on Fenwick array indices for moving through the tree, by starting with operations on a binary indexed tree and conjugating by conversion to and from Fenwick indices. First, in order to fuse away the resulting conversion, we will need a few lemmas.

Proof. Easy proof by induction on Bits. For example, for the inc case, the functions on both sides discard consecutive 1 bits and then flip the first 0 bit to a 1.

Finally, we will need a lemma about shifting zero bits in and out of the right side of a value.

Lemma 6.3 (shl-shr). For all $0 < x < 2^{n+2}$ ,

\[ {({while}\;(not\mathbin{\circ}{test}\;({n}\mathbin{+}\mathrm{1}))\;{shl}\mathbin{\circ}{while}\;{even}\;{shr})\;{x}\mathrel{=}{while}\;(not\mathbin{\circ}{test}\;({n}\mathbin{+}\mathrm{1}))\;{shl}\;{x}}. \]

Formally, the proof is by induction on x. If ${{x}\mathrel{=}{xs}\mathrel{:\!.}{I}}$ is odd, the equality is immediate since ${{while}\;{even}\;{shr}\;{x}\mathrel{=}{x}}$ . Otherwise, if ${{x}\mathrel{=}{xs}\mathrel{:\!.}{O}}$ , on the left-hand side the O is immediately discarded by shr, whereas on the right-hand side ${{xs}\mathrel{:\!.}{O}\mathrel{=}{shl}\;{xs}}$ , and the extra shl can be absorbed into the while since ${{xs}} < 2^{n+1}$ . What remains is simply the induction hypothesis.

With these lemmas under our belt, let’s see how to move around a Fenwick array in order to implement update and query; we’ll begin with update. When implementing the update operation, we need to start at a leaf and follow the path up to the root, updating all the active nodes along the way. In fact, for any given leaf, its closest active parent is precisely the node stored in the slot that used to correspond to that leaf (see Figure 13). So to update index i, we just need to start at index i in the Fenwick array, and then repeatedly find the closest active parent, updating as we go. Recall that the imperative code for update works this way, apparently finding the closest active parent at each step by adding the LSB of the current index:

Let’s see how to derive this behavior.

To find the closest active parent of a node under a binary indexing scheme, we first move up to the immediate parent (by dividing the index by two, i.e. performing a right bit shift); then continue moving up to the next immediate parent as long as the current node is a right child (i.e. has an odd index). This yields the definition:

This is why we used the slightly strange indexing scheme with the root having index 2—otherwise this definition would not work for any node whose active parent is the root!

Now, to derive the corresponding operation on Fenwick indices, we conjugate by conversion to and from Fenwick indices and compute as follows. To make the computation easier to read, the portion being rewritten is underlined at each step.

In the final step, since the input x satisfies $x {\leqslant} 2^n$ , we have ${{inc}\mathbin{\circ}{shift}\;({n}\mathbin{+}\mathrm{1})} < 2^{n+2}$ , so Lemma 6.3 applies.

Reading from right to left, the pipeline we have just computed performs the following steps:

1. Set bit $n+1$

2. Shift out consecutive zeros until finding the least significant 1 bit

3. Increment

4. Shift zeros back in to bring the most significant bit back to position $n+1$ , then clear it.

Intuitively, this does look a lot like adding the LSB! In general, to find the LSB, one must shift through consecutive 0 bits until finding the first 1; the question is how to keep track of how many 0 bits were shifted on the way. The lsb function itself keeps track via the recursion stack; after finding the first 1 bit, the recursion stack unwinds and re-snocs all the 0 bits recursed through on the way. The above pipeline represents an alternative approach: set bit $n+1$ as a “sentinel” to keep track of how much we have shifted; right shift until the first 1 is literally in the ones place, at which point we increment; and then shift all the 0 bits back in by doing left shifts until the sentinel bit gets back to the $n+1$ place. One example of this process is illustrated in Figure 19. Of course, this only works for values that are sufficiently small that the sentinel bit will not be disturbed throughout the operation.

Fig. 19

Adding LSB with a sentinel bit + shifts.

To make this more formal, we begin by defining a helper function atLSB, which does an operation “at the LSB”, that is, it shifts out 0 bits until finding a 1, applies the given function, then restores the 0 bits.

We can formally relate the “shifting with a sentinel” scheme to the use of atLSB, with the following (admittedly rather technical) lemma:

1. 1. ${({f}\mathbin{\circ}{set}\;({n}\mathbin{+}\mathrm{1}))\;{x}\mathrel{=}({set}\;({n}\mathbin{+}\mathrm{1})\mathbin{\circ}{f})\;{x}}$ for any $0 < x < 2^n$ , and

2. 2. ${{f}\;{x}} < 2^{n+1}$ for any $0 < x < 2^n + 2^{n-1}$ .

Then for all $0 < x < 2^n$ ,

\[ {({unshift}\;({n}\mathbin{+}\mathrm{1})\mathbin{\circ}{f}\mathbin{\circ}{shift}\;({n}\mathbin{+}\mathrm{1}))\;{x}\mathrel{=}{atLSB}\;{f}\;{x}}. \]

The proof is rather tedious and not all that illuminating, so we omit it

(an extended version including a full proof may be found on the author’s website, at http://ozark.hendrix.edu/ yorgey/pub/Fenwick-ext.pdf). However, we do note that both inc and dec fit the criteria for f: incrementing or decrementing some $0 < x < 2^n$ cannot affect the $(n+1)$ st bit as long as $n {\geqslant} 1$ , and the result of incrementing or decrementing a number less than $2^n + 2^{n-1}$ will be a number less than $2^{n+1}$ . We can now put all the pieces together show that adding the LSB at each step is the correct way to implement update.

Theorem 6.6 Adding the LSB is the correct way to move up a Fenwick-indexed tree to the nearest active parent, that is,

\[ {{activeParentFenwick}\mathrel{=}{b2f'}\;{n}\mathbin{\circ}{activeParentBinary}\mathbin{\circ}{f2b'}\;{n}\mathrel{=}\lambda {x}\to {x}\mathbin{+}{lsb}\;{x}} \]

everywhere on the range $[1, 2^n)$ . (We exclude $2^n$ since it corresponds to the root of the tree under a Fenwick indexing scheme.)

Proof

We can carry out a similar process to derive an implementation for prefix query (which supposedly involves subtracting the LSB). Again, if we want to compute the sum of [1, j], we can start at index j in the Fenwick array, which stores the sum of the unique segment ending at j. If the node at index j stores the segment [i,j], we next need to find the unique node storing a segment that ends at $i-1$ . We can do this repeatedly, adding up segments as we go.

Staring at Figure 20 for inspiration, we can see that what we want to do is find the left sibling of our closest inactive parent, that is, we go up until finding the first ancestor which is a right child, then go to its left sibling. Under a binary indexing scheme, this can be implemented simply as:

Fig. 20

Moving up a segment tree to find successive prefix segments.

Theorem 6.7 Subtracting the LSB is the correct way to move up a Fenwick-indexed tree to the active node covering the segment previous to the current one, that is,

\[ {{prevSegmentFenwick}\mathrel{=}{b2f'}\;{n}\mathbin{\circ}{prevSegmentBinary}\mathbin{\circ}{f2b'}\;{n}\mathrel{=}\lambda {x}\to {x}\mathbin{-}{lsb}\;{x}} \]

everywhere on the range $[1, 2^n)$ .

Proof