1 files changed, 21 insertions, 59 deletions
diff --git a/TODO.txt b/TODO.txt
index aecf0a2..ffc0772 100644
--- a/TODO.txt
+++ b/TODO.txt
@@ -1,6 +1,11 @@
-TODO big pruning table looks correct, improve speed?
+TODO pruning tables:
-     use small table to prune, visited array...?
+  - go back to nissy-style BFS for both cocsep and eoesep
-     numbers so far (h=0, k=0):
+  - compute selfsim and keep list of representatives
+  - four different ruotines for k=4,2,1 for eoesep
+  - try: do not compute CO, but use its binary representation
+    (x8 memory for cocsep)
+  
+     numbers so far (eoesep h=0, k=0):
     0        1
     1        1
     2        4
@@ -10,13 +15,12 @@ TODO big pruning table looks correct, improve speed?
     6    41605
     7   474128
     8  4953846
+     9 34776317
-TODO checkdata and hash check for cocsep
+TODO checkdata (available from cube.h) and hash check for cocsep
 TODO benchmarks for solve and table generation
-TODO optimization for transform edges only (and test)
-TODO ARM NEON part
-## H48 optimal solver
+## H48 optimal solver (some has already been implemented)
 First compute co + csep. Use csep as a binary number (2^7 instead of 70,
 loose a factor of 1.8 but still fits in a few megabytes or less). Use
@@ -46,16 +50,11 @@ switch. Here NISS may be useful.
 ## Other solvers
-* ptable should contain some extra data at the beginning: an integer (size)
-  a checksum some summary info, maybe even in text form
-* multisolve
-* use threads
 * nxopt (various sizes, for comparison; also use base value probing
  and benchmarking)
 * Coordinate solver for replacing nissy backend (specify in the comments
  that coordinates return 0 if solved)
-* improve light solver with no table; consider using a small, hard-coded
+* simple solver with small table for short solutions
-  table, e.g. H48 corner table?
 ## ARM NEON intrinsics and other architectures
@@ -65,50 +64,32 @@ switch. Here NISS may be useful.
 ## Optimizations
-* check which is faster: foreach_move or simple for loop? same for trans
+* use threads: how to detect at runtime? what is sane number to default to?
+  pthreads or threads.h?
-### General things
+* multisolve with adaptive threading
+* transform edges only for h48 coord calculation
 * Moves: don't do full compose for U*, D*, *2 (I removed this because I
  was using shuffle intructions wrong, should re-do it)
 * Trans: don't do full compose, for some trans composing perm is enough.
  Split out sumco() as a separate function and refactor, optimize.
 * Use multi-move (up to 4/5 moves at once)
-* CO is the worst part of moving, transforming and inverting. Try basing
-  everything on representing the cube without CO and apply it only at the
-  end to check that it is actually solved.
 * see if vcube's method to flip all corners is better
 * find a better way for computing the inverse?
-* Improve avx2 instructions in general
-### Threading
-* THREADS build time option for the number of threads. If set to one,
-  do not include any threading library or code. Try detecting at build
-  time, or set to a sane default (e.g. 8? 16?) for generic builds.
-* pthread or threads.h? I am more familiar with pthread, but threads.h
-  is standard (from C11, so it requires switching to it from C99).
-  Does using threads.h help in any way (e.g. building on Windows)?
 ## Improvements and other things
 * Rename to libnissy (prefix public functions with nissy_?)
-* add centers (and moves...)
+* add centers (and slice moves and rotations)
+  for avx2: centers in the same lane as corners, numbered from 9 to 14
 * for CO: move to bits 5 and 6, no need for padding bit
 * manipulate move sequences (invert, unniss, cleanup, mirror / transform...)
 * NISS: Add mask to moves (e.g. U | NISS where NISS = 32 or something);
  adapt readmoves and writemoves.
-* Consider adding centers and other moves (for avx2: centers in the
+* More I/O formats:
-  same lane as corners, numbered from 9 to 14)
+  reid format
-* More I/O:
  nissy
-  ascii art (color = 1 letter)
+  ascii art (color = 1 letter? color print?)
  twizzle binary https://www.experiments.cubing.net/cubing.js/spec/binary/
-  reid?
-* print ptables (or layout data in such a way that can be printed
-  easily, e.g. first bytes are null-terminated strig and can be
-  printed by user)
-* remove writetrans?
 ## "Front-end"
@@ -135,25 +116,6 @@ For example, to apply the transformation RBm (mirrored RB) to a cube C:
        3. Apply the cube C to the transformed solved cube
        4. Apply the transformations of step 1a and 1b in reverse
-## Roadmap
-* Tests for multisolve
-* More tests for simple solver?
-* Benchmarks?
-* More complex optimal solvers, pruning tables
-* (More) benchmarks
-* Multithreading (build-time option number of threads)
-* Other optimizations
-* Extend cube and moves to include centers
-* NISS
-* Move manipulation utilities
-* Coordinate solvers and other steps
-* More output formats (see https://experiments.cubing.net/cubing.js/3x3x3-formats)
-* Adapters for other languages (at least python)
-* More documentation (or keep all in cube.h?)
-* Rename to libnissy
-* Release 1.0
 ## Future work?
 * A* on GPU? https://github.com/mwarzynski/uw_parallel_a_star

diff --git a/TODO.txt b/TODO.txt index aecf0a2..ffc0772 100644 --- a/TODO.txt +++ b/TODO.txt
@@ -1,6 +1,11 @@
1	TODO big pruning table looks correct, improve speed?	1	TODO pruning tables:
2	use small table to prune, visited array...?	2	- go back to nissy-style BFS for both cocsep and eoesep
3	numbers so far (h=0, k=0):	3	- compute selfsim and keep list of representatives
		4	- four different ruotines for k=4,2,1 for eoesep
		5	- try: do not compute CO, but use its binary representation
		6	(x8 memory for cocsep)
		7
		8	numbers so far (eoesep h=0, k=0):
4	0 1	9	0 1
5	1 1	10	1 1
6	2 4	11	2 4
@@ -10,13 +15,12 @@ TODO big pruning table looks correct, improve speed?
10	6 41605	15	6 41605
11	7 474128	16	7 474128
12	8 4953846	17	8 4953846
		18	9 34776317
13		19
14	TODO checkdata and hash check for cocsep	20	TODO checkdata (available from cube.h) and hash check for cocsep
15	TODO benchmarks for solve and table generation	21	TODO benchmarks for solve and table generation
16	TODO optimization for transform edges only (and test)
17	TODO ARM NEON part
18		22
19	## H48 optimal solver	23	## H48 optimal solver (some has already been implemented)
20		24
21	First compute co + csep. Use csep as a binary number (2^7 instead of 70,	25	First compute co + csep. Use csep as a binary number (2^7 instead of 70,
22	loose a factor of 1.8 but still fits in a few megabytes or less). Use	26	loose a factor of 1.8 but still fits in a few megabytes or less). Use
@@ -46,16 +50,11 @@ switch. Here NISS may be useful.
46		50
47	## Other solvers	51	## Other solvers
48		52
49	* ptable should contain some extra data at the beginning: an integer (size)
50	a checksum some summary info, maybe even in text form
51	* multisolve
52	* use threads
53	* nxopt (various sizes, for comparison; also use base value probing	53	* nxopt (various sizes, for comparison; also use base value probing
54	and benchmarking)	54	and benchmarking)
55	* Coordinate solver for replacing nissy backend (specify in the comments	55	* Coordinate solver for replacing nissy backend (specify in the comments
56	that coordinates return 0 if solved)	56	that coordinates return 0 if solved)
57	* improve light solver with no table; consider using a small, hard-coded	57	* simple solver with small table for short solutions
58	table, e.g. H48 corner table?
59		58
60	## ARM NEON intrinsics and other architectures	59	## ARM NEON intrinsics and other architectures
61		60
@@ -65,50 +64,32 @@ switch. Here NISS may be useful.
65		64
66	## Optimizations	65	## Optimizations
67		66
68	* check which is faster: foreach_move or simple for loop? same for trans	67	* use threads: how to detect at runtime? what is sane number to default to?
69		68	pthreads or threads.h?
70	### General things	69	* multisolve with adaptive threading
71		70	* transform edges only for h48 coord calculation
72	* Moves: don't do full compose for U, D, *2 (I removed this because I	71	* Moves: don't do full compose for U, D, *2 (I removed this because I
73	was using shuffle intructions wrong, should re-do it)	72	was using shuffle intructions wrong, should re-do it)
74	* Trans: don't do full compose, for some trans composing perm is enough.	73	* Trans: don't do full compose, for some trans composing perm is enough.
75	Split out sumco() as a separate function and refactor, optimize.	74	Split out sumco() as a separate function and refactor, optimize.
76	* Use multi-move (up to 4/5 moves at once)	75	* Use multi-move (up to 4/5 moves at once)
77	* CO is the worst part of moving, transforming and inverting. Try basing
78	everything on representing the cube without CO and apply it only at the
79	end to check that it is actually solved.
80	* see if vcube's method to flip all corners is better	76	* see if vcube's method to flip all corners is better
81	* find a better way for computing the inverse?	77	* find a better way for computing the inverse?
82	* Improve avx2 instructions in general
83
84	### Threading
85
86	* THREADS build time option for the number of threads. If set to one,
87	do not include any threading library or code. Try detecting at build
88	time, or set to a sane default (e.g. 8? 16?) for generic builds.
89	* pthread or threads.h? I am more familiar with pthread, but threads.h
90	is standard (from C11, so it requires switching to it from C99).
91	Does using threads.h help in any way (e.g. building on Windows)?
92		78
93	## Improvements and other things	79	## Improvements and other things
94		80
95	* Rename to libnissy (prefix public functions with nissy_?)	81	* Rename to libnissy (prefix public functions with nissy_?)
96	* add centers (and moves...)	82	* add centers (and slice moves and rotations)
		83	for avx2: centers in the same lane as corners, numbered from 9 to 14
97	* for CO: move to bits 5 and 6, no need for padding bit	84	* for CO: move to bits 5 and 6, no need for padding bit
98	* manipulate move sequences (invert, unniss, cleanup, mirror / transform...)	85	* manipulate move sequences (invert, unniss, cleanup, mirror / transform...)
99	* NISS: Add mask to moves (e.g. U \| NISS where NISS = 32 or something);	86	* NISS: Add mask to moves (e.g. U \| NISS where NISS = 32 or something);
100	adapt readmoves and writemoves.	87	adapt readmoves and writemoves.
101	* Consider adding centers and other moves (for avx2: centers in the	88	* More I/O formats:
102	same lane as corners, numbered from 9 to 14)	89	reid format
103	* More I/O:
104	nissy	90	nissy
105	ascii art (color = 1 letter)	91	ascii art (color = 1 letter? color print?)
106	twizzle binary https://www.experiments.cubing.net/cubing.js/spec/binary/	92	twizzle binary https://www.experiments.cubing.net/cubing.js/spec/binary/
107	reid?
108	* print ptables (or layout data in such a way that can be printed
109	easily, e.g. first bytes are null-terminated strig and can be
110	printed by user)
111	* remove writetrans?
112		93
113	## "Front-end"	94	## "Front-end"
114		95
@@ -135,25 +116,6 @@ For example, to apply the transformation RBm (mirrored RB) to a cube C:
135	3. Apply the cube C to the transformed solved cube	116	3. Apply the cube C to the transformed solved cube
136	4. Apply the transformations of step 1a and 1b in reverse	117	4. Apply the transformations of step 1a and 1b in reverse
137		118
138	## Roadmap
139
140	* Tests for multisolve
141	* More tests for simple solver?
142	* Benchmarks?
143	* More complex optimal solvers, pruning tables
144	* (More) benchmarks
145	* Multithreading (build-time option number of threads)
146	* Other optimizations
147	* Extend cube and moves to include centers
148	* NISS
149	* Move manipulation utilities
150	* Coordinate solvers and other steps
151	* More output formats (see https://experiments.cubing.net/cubing.js/3x3x3-formats)
152	* Adapters for other languages (at least python)
153	* More documentation (or keep all in cube.h?)
154	* Rename to libnissy
155	* Release 1.0
156
157	## Future work?	119	## Future work?
158		120
159	* A* on GPU? https://github.com/mwarzynski/uw_parallel_a_star	121	* A* on GPU? https://github.com/mwarzynski/uw_parallel_a_star