Update 2024-09-10.md

Fix minor typos

posts/2024-09-10.md

@@ -38,8 +38,8 @@ impl<S, T> ResultColumns<S, T> {
     /// Not quite `&Result<S, T>` but pretty close.
     fn get(&self, index: usize) -> Result<&S, &T> {
         match self.indexes[index] {
-            Ok(index) => &self.s_store[index],
-            Err(index) => &self.t_store[index],
+            Ok(index) => Ok(&self.s_store[index]),
+            Err(index) => Err(&self.t_store[index]),
         }
     }
 }
@@ -49,7 +49,7 @@ This pattern allows us to store `S` and `T` records separately, but with some ov
 Each element also requires a `Result<usize, usize>`, which .. is the same size as the hypothetical `Result<u64, u8>` we started with.
 So that's not great.
 
-### Succinter data structures
+### Succincter data structures
 
 It turns out that `indexes` stores way more information than we strictly need.
 We need to be able to see which variant, `Ok` or `Err`, an element is, and figure out where to find it in the corresponding store.
@@ -275,4 +275,4 @@ I have a few other things planned, to try and fit other techniques into the same
 For example, many of the string and vector offsets are (or are nearly) linear functions of `index`.
 This happens when you are actually depositing fixed lengths that are not know *a priori*.
 It seems entirely reasonable to encode the offsets as `Result<usize, u8>` indicating either a fixed position, or an edit to a linear interpolation from the previous fixed position.
-Or (goodness) some other more complex interpolation from the previous several points.
+Or (goodness) some other more complex interpolation from the previous several points.