From f4523e0422b1994a6fecba0efb336525d4f81d57 Mon Sep 17 00:00:00 2001 From: Sebastiano Tronto Date: Sun, 28 Dec 2025 20:20:34 +0100 Subject: First update to docs --- doc/h48.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/doc/h48.md b/doc/h48.md index d9ef192..6015b2a 100644 --- a/doc/h48.md +++ b/doc/h48.md @@ -251,15 +251,18 @@ Moreover, as an additional heuristic, in case of a 0 read we also look up another pruning value in a table that takes into account only the position of the edges. This table is small (around 1MB), so repeated accesses to it are not too slow. In practice, this gives a small speed up -of around 5%. 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. - -Previous versions of this implementation (up to commit 6c42463, or -to version 0.2) also included the possibility of a table with 4 bits -per entry, at least for the `h0` case. Such tables did not require -a fallback lookup, but due to their large size they were not less -efficient. Therefore, they have been removed. +of around 5% for random scrambles. However, for small solvers (low values +of h) and positions where corners are close to solved, this fallback +table gives dramatic improvements (up to a factor of 1000x in some +manual tests). + +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. Previous versions of this implementation (up +to commit 6c42463, or to version 0.2) also included the possibility of +a table with 4 bits per entry, at least for the `h0` case. Such tables +did not require a fallback lookup, but due to their large size they were +not less efficient. Therefore, they have been removed. ### Estimation refinements -- cgit v1.3