Fixes typo.

Author: brianburton

_posts/2021-01-01-jimmutables-3.2.1.md

@@ -11,13 +11,13 @@ Actually this post covers the changes from both 3.2.0 and 3.2.1.
 
 ### Simpler, smaller arrays
 
-JImmutableArray has always been the simplest HAMT implementation since it had no need to support collision maps.  It was still a bit more complicated than I liked.  Plus I'd always preferred to the idea of having a single HAMT to serve as a basis for hash sets and maps as well as arrays.  Once 3.1.0 was released I used my enforced non-work time to work on an improved array implementation.
+JImmutableArray has always been the simplest HAMT implementation since it had no need to support collision maps.  It was still a bit more complicated than I liked.  Plus I'd always preferred the idea of having a single HAMT to serve as a basis for hash sets and maps as well as arrays.  Once 3.1.0 was released I used my enforced non-work time to work on an improved array implementation.
 
 The first improvement was exploiting twos compliment to simplify iteration order handling.  The new implementation takes every user provided index and flips its high-order bit (i.e. 0 becomes 1 and vice versa).  This converts the user space index range of signed integers [-2^31,2^31) to an equivalent unsigned range [0,2^32) (`[` means inclusive, `)` means exclusive).  This makes iteration in user signed index order easy as long as our HAMT can support iteration in internal unsigned index order.
 
 Next I decided to take a trick from the AVL tree implementaton and store values internally within the trie rather than just at the leaves.  This complicates the nodes themselves slighly but has the effect of reducing the number of nodes in the trie.  Fewer nodes means lower memory footprint.
 
-To further reduce the number of nodes in the trie I added height compression.  Whenever a parent node detects that a child node would naturally be multiple levels lower in the trie than itself and there is currently no child higher in the trie than the new one it simply stores the child itself without creating its ancestors.  To see how this works assume you have an empty trie.  Next you insert an element that would naturally appear at leve1 4 in the trie.  Without height compression the root would now point to a level 1 node that just has a level 2 node as its child.  The level 2 node would just have a level 3 node as its child.  The level 3 node would have our new value node as its child.  Thus we have a trie of height 4 when all we really wanted was to store a single node!
+To further reduce the number of nodes in the trie I added height compression.  Whenever a parent node detects that a child node would naturally be multiple levels lower in the trie than itself and there is currently no child higher in the trie than the new one it simply stores the child itself without creating its ancestors.  To see how this works assume you have an empty trie.  Next you insert an element that would naturally appear at level 4 in the trie.  Without height compression the root would now point to a level 1 node that just has a level 2 node as its child.  The level 2 node would just have a level 3 node as its child.  The level 3 node would have our new value node as its child.  Thus we have a trie of height 4 when all we really wanted was to store a single node!
 
 With height compresison level 4 node is still created but it becomes the root of the trie and none of the parents are needed. The trie nodes are smart enough to create or remove intermediate nodes as necessary when values are added to or deleted from the trie.  This keeps the array's trie as small as possible at all times.