efrantar / rob-twophase Goto Github PK

Hello,,

Did -DF5 option work in the last version of the code because I have some troubles with it?
I did a test to solve a scramble by compiling with -DF5 and no solution is returned by the program.
I've been looking through the code but nothing works. It seems that variable sol is empty.

If you know where this could come from I would be happy to exchange with you.

I have compiled rob-twophase using the provided makefile on Ubuntu using GCC 5.4.0.

During compilation I get this error mesage:

src/coord.cpp: In function ‘void coord::init_move(uint16_t (*)[18], int, int (*)(const cubie::cube&), void (*)(cubie::cube&, int), void (*)(const cubie::cube&, const cubie::cube&, cubie::cube&), bool)’:
src/coord.cpp:233:30: error: ‘ffsll’ was not declared in this scope
           int m = ffsll(moves) - 1;

ffs is defined in the header strings.h, while ffsll is defined in the header string.h:
https://man7.org/linux/man-pages/man3/ffsll.3.html
However, only strings.h is included.

This applies to coord.cpp, prun.cpp and solve.cpp as they all use ffsll.
If I add #include <string.h> to these files, it compiles without errors.

I have compiled rob-twophase using the -DAX flag.
If I run ./twophase -t 8 -n 20 and let it solve this cube:
solve RFLDUFLDURRBBRDURRULFBFLDUBLFLLDUBDDDRFBLUUUFDLFBBRBFR
One of the solutions found is:
(U D') F' L' D' (F B2) (R L2) (U D) (F' B2) U U2 F' R2 D2 F L2 B' (16)
which has a U move followed by a U2 move!

Is this a bug or does the algorithm allow adjacent moves to be on the same face?

Here the full error code:
C:\Users\Besitzer\Desktop\rob-twophase>make
g++ -std=c++11 -lpthread -O3 -DF5 -c -o src/coord.o src/coord.cpp
src/coord.cpp: In function 'int coord::get_combperm(const int*, int, int)':
src/coord.cpp:72:21: error: 'ffs' was not declared in this scope
72 | int min_cubie = ffs(mask) - 1;
| ^~~
src/coord.cpp: In function 'void coord::init_move(uint16_t ()[18], int, int ()(const cubie::cube&), void ()(cubie::cube&, int), void ()(const cubie::cube&, const cubie::cube&, cubie::cube&), bool)':
src/coord.cpp:233:19: error: 'ffsll' was not declared in this scope
233 | int m = ffsll(moves) - 1;
| ^~~~~
make: *** [: src/coord.o] Error 1

Is it possible to have this functionality present here => RubiksCube-TwophaseSolver to be possible to solve the cube to any state other than the solved one?

Hi!

In the README file it is mentioned that

cube20src clearly remains the best choice for batch-solving a very large number of cubes

So, if batch solving is our priority is cube20src actually better than rob-twophase?

I have a machine running both Ubuntu and macOS natively. rob-twophase runs as fast as expected on Ubuntu, while it is very slow on macOS:

$ ./twophase -t 1 -l 22 -m 10000  # compiled without extra solve mode defines
solve UDFUURRLDBFLURRDRUUFLLFRFDBRBRLDBUDLRBBFLBBUDDFFDBUFLL

Ubuntu: 0.2 ms
macOS: 430 ms, or 1200 ms, or even > 10000 ms.
The time it takes is different every time I restart twophase, but it is pretty consistent for a session. I have no other programs running.

I used the provided makefile for compilation and the compiler provided by macOS:

$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Any ideas?

I get
terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted
When running ./twophase after making with the flags -DQT -DAX
On Raspberry Pi
Without any flags works though.

Update: It works on raspberry pi 4 with 4gb of ram but not pi 3b

The solutions are ordered using the uncompressed length, and the uncompressed length is shown after the (compressed) move string. This seems to be intentional, judging from the comment. However, for me the expected output of the solver should be the shortest solution found (or the -n shortest solutions, in ascending ordering).

This could be achieved by compressing a discovered solution before it is added to the sols priority queue of solutions in the function report_sol: