Merge pull request #31 from gvelim/gvelim-patch-1

Update merge_in_place.md

csx3/src/merge_in_place.md

@@ -231,11 +231,11 @@ Phase 2 is now complete. **As if by magic** everything is now in position and or
 
 ## Optimisations & other uses
 1. Given the non-sequential movement of `p'` and for less than 500 elements we can map `p -> p'` by searching serially within the `[c .. left_array.len()]` range. However, this approach and under larger sets, has O(n^2) performance hence an alternative is to forward pre-calculate `p'` during each swap. This eliminates the nested search loop which results to 10x increase of performance (current implementation)
-2. Given the 4th property we can reduce the Index Reflector to `left_array.len()` reducing the memory requirements from 2(n+m) to (2n+m) in case of mergesort
+2. Given the 4th property we can reduce the Index Reflector to `left_array.len()` reducing the memory requirementsfrom 2(n+m) to (2n+m) in case of mergesort
 3. In addition to 4th property and given the arrays are adjacent the VirtualSlice becomes a pointer to a reconstructed parent array hence the overall memory impact becomes O(n) * sizeof(usize)
 4. Given the 1st property we can
-5. Develop a "sort mask array" through which we can access the source array segments in order and without the need of permanently mutating them
-   1. [VirtualSlice::merge_shallow](./merge_lazy.md)
-6. Such "sort mask" can be imposed or "played onto" the source segments hence mutating them only when is needed
-   1. [VirtualSlice::impose_shallow_merge](./merge_lazy.md)
+   1. Develop a "sort mask array" through which we can access the source array segments in order and without the need of permanently mutating them
+      1. [VirtualSlice::merge_shallow](./merge_lazy.md)
+   2. Such "sort mask" can be imposed or "played onto" the source segments hence mutating them only when is needed
+      1. [VirtualSlice::impose_shallow_merge](./merge_lazy.md)