2 files changed, 29 insertions, 5 deletions

diff --git a/doc/h48.md b/doc/h48.md
index 323453a..678e160 100644
--- a/doc/h48.md
+++ b/doc/h48.md
@@ -230,9 +230,8 @@ can be one of three kinds:
   If the base value is `b`, a pruning value of 1, 2 or 3 can be used directly
   as a lower bound of b+1, b+2 and b+3 respectively. However, a value of 0
   could mean that the actual lower bound is anything between 0 and b, so we
-  cannot take b as a lower bount. Instead we have to use a pruning value from
-  another table, for example the corner-only table mentioned in the previous
-  section, or a completely new one.
+  cannot take b as a lower bound. Instead we have to use a pruning value from
+  another table - see the section "Fallback tables" below.
 * 1 bit per entry, or `k1`: With one bit per entry, the only information we
   can get from the pruning table is wether or not the current position
   requires more or fewer moves than a fixed base value b. This can still be
@@ -240,6 +239,24 @@ can be one of three kinds:
   pruning values.
   (Work in progress - `k1` tables not available in the code yet)
 
+### Fallback tables
+
+When a pruning table does not store the exact lower bound value, for
+example in the case of `k2` table as described above, we need to refine
+our estimate using another table, which we call *fallback table*.
+In the current implementation, we actually use two different tables:
+
+* **h0** table: for larger `k2` tables we get a fallback value from the full
+  table for the **h0** coordinate.
+* edges-only table: to improve the pruning value for certain specific
+  scrambles, namely whose with solved corners such as the superflip,
+  we employ a second table that takes into account the edges of a full
+  **h11** coordinate. This table is small (around 1MB).
+
+More tables could be used to refine the fallback estimate, but each
+additional table leads to longer lookup times, especially if it is
+too large to fit in cache.
+
 ### Estimation refinements
 
 After computing the pruning value, there are a number of different tricks
@@ -285,6 +302,12 @@ as described above. For doing this, we need to replace the cube with its
 inverse, and keep track of the moves done from now on so that we can
 invert them at the end to construct the final solution.
 
+When this technique is used, it is also possible to avoid some table
+lookups: if the last move applied to the cube is a 180° move *on the
+inverse position*, then the coordinate on the normal position has not
+changed. Thus if we keep track of the last computed pruning value,
+we can reuse it and avoid an expensive table lookup.
+
 ### Other optimizations
 
 Other possible (low-level) optimizations include:
@@ -344,7 +367,7 @@ don't have this much memory.
 
 ### 2 bits tables with for h0 and h11
 
-(Work in progress - currently I there is no specialized routine for
+(Work in progress - currently there is no specialized routine for
 computing 2 bits table for "real" coordinates; instead, an optimized
 version of the generic method explained below is used)
 
diff --git a/doc/transformations.md b/doc/transformations.md
index a180ce6..65212ea 100644
--- a/doc/transformations.md
+++ b/doc/transformations.md
@@ -6,4 +6,5 @@ For example, to apply the transformation RBm (mirrored RB) to a cube C:
         1. Apply a mirror along the M plane to the solved cube
         2. Rotate the mirrored cube with z' y2
         3. Apply the cube C to the transformed solved cube
-        4. Apply the transformations of step 1a and 1b in reverse
+        4. Apply the transformations of step 2 in reverse
+        5. Apply the transformations of step 1 in reverse