nissy-core/src/solvers/solutions.h, branch masterThe "engine" of nissy, including the H48 optimal solver.https://git.tronto.net/nissy-core/atom?h=master2026-04-06T13:55:33ZMake the project build with Microsoft's broken C compiler.2026-04-06T13:55:33ZSebastiano Trontosebastiano@tronto.net2026-04-06T13:55:33Zurn:sha1:fc41f7917531693680b5baf71ffe38c47333fe84
MSVC is not fully C11-compliant, even when compiling with /std:c11.
Some changes were needed to make the codebase compatible. Notably, the
notation a[static N] and a[n] for function parameters of array type is
not supported, so that had to be hidden behind a macro. Atomic types
are also an experimental feature, apparently, but at least they work
with the correct compiler flag.
One thing that MSVC does well, however, is warning on integer conversions
on /W4 level. I am not sure if Clang and GCC have something similar,
so I took this chance to fix some of these.
Improve performance of H48 solver with prefetching2026-01-12T17:09:43ZSebastiano Trontosebastiano@tronto.net2026-01-12T17:09:43Zurn:sha1:9a013b7c68f94e6be0fe8748c9012a441fe0273f
With this commit we re-structure how the node expansion in the
H48 solution search works to allow prefetching of pruning values,
showing performance improvements in the range of 30-45% on x86,
depending on table size and solution length.
A small bug fix related to appending solutions is included in this commit.
Fix duplicate solutions, overflow in maxsols and improve symmetry reduction for H48.2025-11-24T15:32:11ZSebastiano Trontosebastiano@tronto.net2025-11-23T15:16:31Zurn:sha1:147b0c3c4615c32478a4923242909b8ae5a30d03
This commit fixes two bugs:
- A bug that caused duplicates solutions for symmetric scrambles.
- An overflow in the maxsols parameter for the H48 solver, which
caused it to find much fewer solutions than existed.
Moreover, the H48 solvers has been improved by reducing by symmetry not
only from the starting position, but also up to the first 4 moves.
Added API function for solution variations2025-08-07T13:28:01ZSebastiano Trontosebastiano@tronto.net2025-08-07T13:09:46Zurn:sha1:5355de2921126e2b75e24abd57e17556e22a6ed0Fix bug2025-07-31T11:09:42ZSebastiano Trontosebastiano@tronto.net2025-07-31T11:09:42Zurn:sha1:bf3497420c9a12397dc13a34faf3ce3e456f3aa7Fixed bug with counting solutions for coordinate solver2025-07-30T14:35:25ZSebastiano Trontosebastiano@tronto.net2025-07-30T14:35:25Zurn:sha1:36c317ebd1cf1dba8a8cbec494f4d3971e6cefd3Cleanup some TODOs2025-07-29T08:55:29ZSebastiano Trontosebastiano@tronto.net2025-07-29T08:55:29Zurn:sha1:52c21640508c3fc668107778ae027ff4428ebd89Removed VLA notation from function parameters.2025-05-27T07:03:51ZSebastiano Trontosebastiano@tronto.net2025-05-27T07:03:51Zurn:sha1:7c934801f88c640970ad41b5ddd39f4e39609f28
I found out that this gives undefined behavior when then size is 0.
Better not to have it at all, it is confusing for other developers anyway.
Do all loggin in main thread2025-05-23T14:54:59ZSebastiano Trontosebastiano@tronto.net2025-05-23T14:48:58Zurn:sha1:c6a77f30f64be73a5e55e06336975f2ecfbb2324
Before this committ, the solver (via the generic solution-appender
routines in src/solve/solutions.h) and the H48 data generator did some
logging in the worker threads, without using any locks. This was not nice,
but in practice it did not cause any problem, because the log messages
were rare.
However, this turned out to be a problem when building to WASM, because
web workers do not have access to the main JS memory, and therefore
they cannot call functions from the main JS. This includes not only the
callback functions for logging, but also those for polling the status
of the solver (run / pause / stop).
This commit fixes this at the cost or being somewhat inelegant: the
solutions are not logged as they are found, but only every 500ms.
Adjusted solvers, fixed bug2025-04-23T12:52:58ZSebastiano Trontosebastiano@tronto.net2025-04-23T12:42:28Zurn:sha1:039267a278bb9e0580e8aebd85ef5f3ed774688f