| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Another fix to coord | Sebastiano Tronto | 2022-06-01 | 1 | -2/+2 |
| | | |||||
| * | Couple of fixes in coordinates | Sebastiano Tronto | 2022-06-01 | 1 | -2/+2 |
| | | |||||
| * | Fixed some bugs - still more testing needed | Sebastiano Tronto | 2022-06-01 | 1 | -1/+1 |
| | | |||||
| * | Big changes to coordinate system: remove "anti-index" in favor of a more ↵ | Sebastiano Tronto | 2022-05-31 | 1 | -319/+241 |
| | | | | | 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! | ||||
| * | Added a new pruning table (equivalent to nxopt31). I have not tested it yet, ↵ | Sebastiano Tronto | 2021-12-16 | 1 | -2/+84 |
| | | | | | | | | 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. | ||||
| * | Faster and nice pruning table generation. Can still be improved with ↵ | Sebastiano Tronto | 2021-12-08 | 1 | -13/+0 |
| | | | | | multithreading. | ||||
| * | Fixed a problem with htr-drud coordinates. The corresponding pruning table ↵ | Sebastiano Tronto | 2021-11-13 | 1 | -3/+38 |
| | | | | | also changed, hopefully the new one is correct. | ||||
| * | I tried to remove the dependence on antindex in order to get rid of them | Sebastiano Tronto | 2021-11-12 | 1 | -3/+5 |
| | | | | | | | | 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. | ||||
| * | Some cleanup for antindeces; pointed out which return a consistent cube and ↵ | Sebastiano Tronto | 2021-11-12 | 1 | -20/+54 |
| | | | | | which do not | ||||
| * | Fixed anti-index for eofbepos. It did not compute a value for eorl, which | Sebastiano Tronto | 2021-11-12 | 1 | -1/+28 |
| | | | | | | | causes problems when using this coordinate combined with symmetries (e.g. in symcoord khuge, drud and similar). This actually reverts a change that I made before the first commit of v2. | ||||
| * | Rewritten from scratch. Welocme nissy 2.0! | Sebastiano Tronto | 2021-11-11 | 1 | -0/+522 |
