From e864e23e3ec315d5969281c51f24521cde30792a Mon Sep 17 00:00:00 2001 From: Sebastiano Tronto Date: Fri, 12 Nov 2021 19:59:18 +0100 Subject: I tried to remove the dependence on antindex in order to get rid of them once and for all. I successfully removed from the pruning table generation part by using an alternative (slower) method, but then I realized that I also use antindexes when generating symmetry data. So I reverted to the original pruning table computation method, but I left the alternative way there, commented. --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index fc71f2d..de56f9d 100644 --- a/README.md +++ b/README.md @@ -109,8 +109,9 @@ table to solving EO with HTM moveset and this coordinate would have values 0 (fo There is one caveat: each coordinates also needs an inverse function that takes a coordinate value and returns a cube which has that coordinate. This is in general more complicated, but luckily the cube does not need to be fully built or consistent. -This inverse-coordinate is used only in one specific step when building pruning tables -to avoid using up hundreds of Gb of memory. +This inverse-coordinate is used only in one specific step when generating symmetry +data, and I don't know if it is possible to avoid it (maybe it is). It is also used +when building pruning tables, but in that case it is avoidable. Note: this part is different from what Cube Explorer does. Overall I think it is conceptually easier, although in practice it was still hard to implement. -- cgit v1.3