It is because of the f-strings, this feature was introduced in python3.6 but you are running 3.5. I should have the installer catch this and raise a better error.
In a nutshell though if you upgrade to python 3.6 or later you should be good.
I write code for a living and as a hobby :) I do a lot of lego mindstorms projects for fun and one of those was a rubiks cube solving robot which led me down this path of writing a NxNxN rubiks cube solver.
I just pushed a fix, the odds of hitting that bug were 1 in 40,320!! :) There is one more bug to fix here, for some reason the entire cube rotations (x, y, z moves) are not being removed as they should be.
It takes about 4s per move so for say a 5x5x5 if you want to do 70 moves to scramble you are looking at about 5 minutes.
I have never been to a cube solving competition...how many cubes do volunteers end up scrambling? I take it they are given a set of moves to apply to scramble a cube a...
I built this, it can solve 2x2x2 up to 6x6x6:
It would be an easy change to feed it a sequence of steps to apply to a solved cube to scramble it a specific way.
FYI I have installed my solver on a pi3 and will use that for testing in the future. 4x4x4 takes ~10s, 5x5x5 takes ~180s, 6x6x6 and larger run out of RAM and do not produce a solution. Am going to work on making this run faster on pi3 but the solutions will be a little longer than "--normal" mode.
Wow you are seeing some really long times. Can you do a `git pull` and make sure you are running the latest? I checked in some fixes the other day that should bring down the 7x7x7 times.
Can you cut-n-paste the error you are getting on the burps? With 8GB you should not be running out of...
In every (if not all) cases the cube-solver program would go look on the internet and download the .gz file
Let's focus on this part first...it will do this if the size of the file that you have isn't the size we are looking for. Can you do the
$ git pull
$ python setup.py build
$ sudo python3...
yep, I am able to solve that one without issue. If you run out of memory and start swapping when python calls subproces.check_output() to launch kociemba it will barf...I bet that is what is happening. When the solver isn't running how much free memory do you have? The 555 solver should take...
That is weird, kociemba does not barf for me
ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$ kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR
U2 D2 R U B L F B R D B2 R B2 U L2 U2 F2 U B2 U' R2 F2
Are you running kociemba from...
yeah that 4x4x4-step31-reduce333-edges.hash-cost-only table takes about ~450M, that is the one I am rebuilding, I may be able to cut that in half.
For 555 I just added a "--min-memory" option that tells it to download a much smaller tables for one of the phases (it will take longer to find a...
It is just 1G for 444 and 600M for 555, not 1.6G for 555. The reason being the 555 solver doesn't need the 444 solver at all but 666 and larger NxNxN even cubes do create an instance of the 444 solver.
I just pushed another change (do the 'git pull' and 'setup.py install' again) that brings it...
You can ignore the warnings...I need to change the loglevel on those that is misleading.
Can you try the following? This should fix the lookup-table-5x5x5-step40-LR-t-centers-solve.txt error
$ cd ~/rubiks-cube-NxNxN-solver
$ git pull
$ sudo python3 setup.py install
I added memory...