From 7946c8efc2e2a44a8e78e1263c1691ce9f412a09 Mon Sep 17 00:00:00 2001 From: Sebastiano Tronto Date: Thu, 18 Jul 2024 11:09:50 +0200 Subject: Converted set to map --- TODO.txt | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) (limited to 'TODO.txt') diff --git a/TODO.txt b/TODO.txt index 6175672..00b85c0 100644 --- a/TODO.txt +++ b/TODO.txt @@ -1,14 +1,38 @@ Bug in esep table generation - - Re-do stats + - add pre-computation of h48 coordinates at distance <=7? + - unit tests (but how do I test? just leave it there to check regressions) - Add long-running test for h0k4 (maybe as a tool?) - - try DFS for h0 solver - - use dfs for computing big table, save distance %3 until the last two steps, - then clean the table and double loop over moves to fill the value - - dfs for tables with h=1 to 10? - + - compute all tables for h<11 + - compute visited up to a fixed depth (7? 8?) + - compute additional step (if needed) to fill <=base + - brute-force the last 2 steps (only 18 moves + 18*15 move pairs) + - compare with known h0 results (from long-running test) + - compute table for h=11 + - is is worth pre-computing stuff? + - can it be unified to the other computation, or is it much better + to do it ad hoc? + - optimize + - use cached values for invcoord_esep? check if it is faster + +(OLD: - Fails for UFRUFU, try command ./run solve -solver H48 -options "2;20" -n 1 -M 10 -cube \ "$(./run frommoves -moves "UFRUFU")" +) + +table base for k=2 (4 most common values start at) + 0 8 + 1 8 + 2 8 + 3 8 or 9 (very close) + 4 9 + 5 9 + 6 9 + 7 9 or 10 (very close) + 8 10 + 9 10 + 10 10 + 11 11 Solver - cleanup h48 solver -- cgit v1.3