| Commit message (Collapse) | Author | Files | Lines | ||
|---|---|---|---|---|---|
| 2023-05-01 | Split nissy in other repos, see README.md | Sebastiano Tronto | 1 | -360/+0 | |
| 2023-03-05 | I made a mess, but it works. Still need to implement new optimal solver. | Sebastiano Tronto | 1 | -8/+28 | |
| After that, a big redesign is due. | |||||
| 2023-02-10 | Added (just a few) tests for alg and added fields to alg struct | Sebastiano Tronto | 1 | -0/+4 | |
| 2022-10-28 | Quick push warning message | Sebastiano Tronto | 1 | -0/+1 | |
| 2022-10-09 | Finished fst, added tests. STILL NOT WORKING. | Sebastiano Tronto | 1 | -1/+2 | |
| 2022-09-10 | Added fst_cube prototypes | Sebastiano Tronto | 1 | -0/+16 | |
| 2022-09-10 | Modified pruning table generation (new compressed) + website update | Sebastiano Tronto | 1 | -9/+3 | |
| 2022-09-06 | Removed some code preparing for moving optimal solver away from general ↵ | Sebastiano Tronto | 1 | -50/+14 | |
| coordinate solving. Kept symcoord for coordinate solving. | |||||
| 2022-09-06 | Symcoord version of nissy. Interesting idea, but performance are | Sebastiano Tronto | 1 | -89/+87 | |
| actually slower. AT THIS STAGE NISSY IS NOT USABLE. | |||||
| 2022-06-01 | parallelized genptable_fixnasty | Sebastiano Tronto | 1 | -0/+1 | |
| 2022-06-01 | Fixed some bugs - still more testing needed | Sebastiano Tronto | 1 | -0/+1 | |
| 2022-05-31 | Big changes to coordinate system: remove "anti-index" in favor of a more ↵ | Sebastiano Tronto | 1 | -3/+4 | |
| kociemba-like move function for each coordinate. This should speedup the table generation step. WARNING: nissy might not be 100% functional at this stage, TESTING needed! | |||||
| 2022-03-15 | Prepare for big changes in coordinates | Sebastiano Tronto | 1 | -1/+5 | |
| 2022-02-27 | Moved random_cube() from cube.c to commands.c and fixed a bug in corners ↵ | Sebastiano Tronto | 1 | -1/+1 | |
| only and edges only scrambles. Added fmc scrambles (with R'U'F). Updated manpage for scramble and cleanup. | |||||
| 2021-12-27 | Added option -i to accept scramble(s) from stdin, very useful for batch mode | Sebastiano Tronto | 1 | -0/+2 | |
| 2021-12-26 | Added scramble command | Sebastiano Tronto | 1 | -0/+2 | |
| 2021-12-26 | Better trans-detection system (for e.g. drfin for HTR scramble) | Sebastiano Tronto | 1 | -1/+3 | |
| 2021-12-25 | Added -O option for solve (specify number of moves within optimal) | Sebastiano Tronto | 1 | -1/+1 | |
| 2021-12-24 | Added -c option for solve | Sebastiano Tronto | 1 | -0/+1 | |
| 2021-12-23 | Added the possibility to compress tables to 2 bits per entry. | Sebastiano Tronto | 1 | -0/+5 | |
| This is done similarly to nxopt: one base value is selected and entries are memorized based on that base value. Values higher than base+3 are returned as base+3 (still a valid estimate) and values lower or equal to base require a lookup on a "fallback" table, which must give a valid estimate for the larger one (e.g. nxopt31 or khuge can fallback to drud_sym16). I have also added some info to the pruning table files: base value and distribution. Unfortunately this means that everyone who has used nissy 2.0beta has to re-generate the tables. | |||||
| 2021-12-16 | Added a new pruning table (equivalent to nxopt31). I have not tested it yet, ↵ | Sebastiano Tronto | 1 | -9/+14 | |
| it takes a while to generate. Plus I have done a whole lot of refactoring in random places because I cannot focus on one thing at the time. | |||||
| 2021-12-13 | Faster optimal solver. | Sebastiano Tronto | 1 | -18/+14 | |
| This is a pretty big one, but unfortunately performance only improved by about 5%. I implemented one of the main ideas of nxopt, that is switching to the inverse scramble on the fly if it gives a lower branching factor. On the one hand it makes sense that it does not have such a huge impact, since it only rarely happens that we do have a lower branching factor on inverse, but on the other hand I am quite sad that the improvement is barely noticeable :-( Maybe the problem is that I have introduced a lot of new overhead and I can improve that in the future. Or maybe I am just overlooking something stupid. | |||||
| 2021-12-09 | Multi-threaded pruning table generation - now it's actually fast :) | Sebastiano Tronto | 1 | -2/+3 | |
| 2021-12-08 | Just refortmatting and added one type | Sebastiano Tronto | 1 | -149/+162 | |
| 2021-12-08 | tiny cleanup | Sebastiano Tronto | 1 | -1/+1 | |
| 2021-12-08 | Faster and nice pruning table generation. Can still be improved with ↵ | Sebastiano Tronto | 1 | -2/+2 | |
| multithreading. | |||||
| 2021-12-07 | Little performance improvement in optimal solver - more to come! | Sebastiano Tronto | 1 | -9/+27 | |
| 2021-12-06 | Fixed typo in comment | Sebastiano Tronto | 1 | -1/+1 | |
| 2021-11-20 | Multithreading seems to be working now, it was easier than expected! | Sebastiano Tronto | 1 | -105/+126 | |
| 2021-11-17 | Use inttypes.h macros to print uint64_t variables (this requires -std=c99). ↵ | Sebastiano Tronto | 1 | -1/+1 | |
| Added a couple of TODOs | |||||
| 2021-11-15 | Load all necessary pruning tables for a step before the actual solving process | Sebastiano Tronto | 1 | -0/+2 | |
| starts. This is in preparation for multi-threaded solving (but don't get hyped, it will take time). | |||||
| 2021-11-12 | I tried to remove the dependence on antindex in order to get rid of them | Sebastiano Tronto | 1 | -0/+1 | |
| 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. | |||||
| 2021-11-11 | Rewritten from scratch. Welocme nissy 2.0! | Sebastiano Tronto | 1 | -0/+286 | |
