• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

SpeedSolving Master beta 2 released!

GRVigo

Member
Joined
Jan 29, 2020
Messages
179
Location
Vigo, Spain
I just released a new version (beta 2) of my solver application "SpeedSolving Master". You can download it from my GitHub account. It's free software under the GNU General Public License.

For Windows (64 bits) download from this link.

This is a portable version with all needed libraries. Unzip it and double click over SSMaster.exe file. Nothing outside the app folder will be written.​

For GNU/Linux (64 bits) you have this other download link.

It's similar to the Windows version, but QT5 libraries are not included, they must be already installed in your system. If you use a KDE environment, they should be installed. Don't forget to give execution permissions to the ssmaster file: chmod +x ssmaster. Sorry, but I don't know much about creating Linux packages.​

Changes from the previous version:
  • There is a new interface, easier to understand and use.
  • New methods supported: Mehta and CEOR (YruRU variant only).
  • There is an experimental feature to evaluate scrambles, I will explain it in detail in a future post.
  • The estimated search time is removed, it was very imprecise.

Some notes:
  • There isn't a Cancel button, if you start a search you have to wait to finish or kill the app. I will try to implement this in the final release.
  • My English level is intermediate-low, so probably there are a lot or mistakes in the texts. I'll appreciate any correction.
  • I'm implementing Nautilus method, and LEOR will be the next. If you want other method or variant supported by this solver, please, let me know.
  • I'll appreciate any suggestion or error report.
I mention here people who have shown interest about this application: @TheCubingCuber347 @tsmosher @OtterCuber @abunickabhi @J727S @Melkor @cuberswoop @Filipe Teixeira @AlgoCuber @JohnnyReggae @BenChristman1 @MuaazCubes @CubeRed
1649686744471.png
 
Last edited:

Silky

Member
Joined
Apr 5, 2020
Messages
873
@GRVigo Just a few notes:

(1) There are some problems with the program not responding
(2) Sometimes certain methods will not produce and solution (I think this has to do with the non-response issues)
(3) Sometimes more advanced solutions produce lower efficiency. Example:
(a) Full step L6E version will produce longer solutions then full step L6E
(b) ZBLL will produce longer solutions than COLL/EPLL.
(4) Movecount averages:

CFOP-OLL/PLL: 44 ETM
CFOP-EO+ZBLL: 43 ETM

Roux Full step: 39 ETM
Roux 1-Look: 40 ETM

Petrus-COLL+EPLL: 34 ETM
Petrus-ZBLL: 34 ETM

ZZ-COLL/EPLL: 47 ETM
ZZ-ZBLL: 45 ETM


Mehta-TDR: 40 ETM

This isn't comprehensive by any means, so take with a huge grain of salt. But as noted before Roux stands out. So a far as movecount discrepancy.. don't know if this just needs bit more optimization. Also, I generated these with a medium amount of solves, so perhaps that may be the problem on my end.

(5) Really enjoy this program, amazing work. Excited to see other methods added. Really found it interesting that COLL/EPLL v ZBLL didn't make a huge difference. Usually it's projected to save on average 5 moves (with optimal ergo). Goes to show how good COLL/EPLL is. Would be interested to know which algs are used tho, move optimal vs ergo optimal? Would be cool to incorporate the movecount coefficient calc. Seems like it be an excellent tool for project average movecount. This is something I think is pretty important since we don't have a standard on average movecount calculations. If you're taking Method recommendation lmk!!

Again, amazing!
Cheers!!
 

GRVigo

Member
Joined
Jan 29, 2020
Messages
179
Location
Vigo, Spain
@GRVigo Just a few notes:

(1) There are some problems with the program not responding
I know this problem exists. I tryed to keep the app interface reponsive while searching, but I can't make it work. I don´t have many experience with QT libraries, and I will work in improve this in next releases.

(2) Sometimes certain methods will not produce and solution (I think this has to do with the non-response issues)
The non-response issue doesn't affect the solutions. It's normal that you don't get solutions with some scrambles and configurations. The fast search makes a very light search and some times it's not possible to get results. If this happends you should change the speed to a lower speed (speed is the most important parameter to get more and better results), but it lasts more time (limit the orientations and/or the amount of solves to avoid very long search times).

(3) Sometimes more advanced solutions produce lower efficiency. Example:
(a) Full step L6E version will produce longer solutions then full step L6E
(b) ZBLL will produce longer solutions than COLL/EPLL.
I understand that this happends using the same scramble each time. Please, note that I search efficient solutions only for the first steps of the methods. Then I apply predefined algorithms to complete the solves. Perhaps the algsets that I use are not the most efficient, I will work to improve this.

To choose which sequences of movements are better I perform an evaluation, and this evaluation it's in some cases subjective. I'm not a master using this methods (I just learned them while programming). That's why in some methods you see low efficiency, because this solver tryes to give you the best solutions in a "human way", and the human who write the code (me) is not a good speedsolver. I also take a lot of information from the example solves forum and tryed to apply it to the solver, so the solver is also a reflection of the forum users!

(4) Movecount averages:

CFOP-OLL/PLL: 44 ETM
CFOP-EO+ZBLL: 43 ETM

Roux Full step: 39 ETM
Roux 1-Look: 40 ETM

Petrus-COLL+EPLL: 34 ETM
Petrus-ZBLL: 34 ETM

ZZ-COLL/EPLL: 47 ETM
ZZ-ZBLL: 45 ETM


Mehta-TDR: 40 ETM

This isn't comprehensive by any means, so take with a huge grain of salt. But as noted before Roux stands out. So a far as movecount discrepancy.. don't know if this just needs bit more optimization. Also, I generated these with a medium amount of solves, so perhaps that may be the problem on my end.
The evaluation of the solves needs improvement. I just implemented Nautilus (L5E & LSLL variants) and LEOR (A & B variants), they will be avaliable in the next release, but now I should stop adding more methods or variants and perhaps I should work in get better solutions and improving the algsets.

(5) Really enjoy this program, amazing work. Excited to see other methods added. Really found it interesting that COLL/EPLL v ZBLL didn't make a huge difference. Usually it's projected to save on average 5 moves (with optimal ergo). Goes to show how good COLL/EPLL is. Would be interested to know which algs are used tho, move optimal vs ergo optimal? Would be cool to incorporate the movecount coefficient calc. Seems like it be an excellent tool for project average movecount. This is something I think is pretty important since we don't have a standard on average movecount calculations. If you're taking Method recommendation lmk!!

Again, amazing!
Cheers!!
Are you the same Silky than proposed the L5E/TNCLL variant for Nautilus method? Because I implemented your algset a few days ago and it works great.

If you, or someone else, are interest in other methods or variants be added to the solver, please let me know.

Thanks a lot for your notes, they are very helpful!
 

Silky

Member
Joined
Apr 5, 2020
Messages
873
I know this problem exists. I tryed to keep the app interface reponsive while searching, but I can't make it work. I don´t have many experience with QT libraries, and I will work in improve this in next releases.


The non-response issue doesn't affect the solutions. It's normal that you don't get solutions with some scrambles and configurations. The fast search makes a very light search and some times it's not possible to get results. If this happends you should change the speed to a lower speed (speed is the most important parameter to get more and better results), but it lasts more time (limit the orientations and/or the amount of solves to avoid very long search times).


I understand that this happends using the same scramble each time. Please, note that I search efficient solutions only for the first steps of the methods. Then I apply predefined algorithms to complete the solves. Perhaps the algsets that I use are not the most efficient, I will work to improve this.

To choose which sequences of movements are better I perform an evaluation, and this evaluation it's in some cases subjective. I'm not a master using this methods (I just learned them while programming). That's why in some methods you see low efficiency, because this solver tryes to give you the best solutions in a "human way", and the human who write the code (me) is not a good speedsolver. I also take a lot of information from the example solves forum and tryed to apply it to the solver, so the solver is also a reflection of the forum users!


The evaluation of the solves needs improvement. I just implemented Nautilus (L5E & LSLL variants) and LEOR (A & B variants), they will be avaliable in the next release, but now I should stop adding more methods or variants and perhaps I should work in get better solutions and improving the algsets.


Are you the same Silky than proposed the L5E/TNCLL variant for Nautilus method? Because I implemented your algset a few days ago and it works great.

If you, or someone else, are interest in other methods or variants be added to the solver, please let me know.

Thanks a lot for your notes, they are very helpful!
Yes I did propose the TNCLL variant. Was trying to find a solution to the inefficiency of last pair. Also proposed a version with VH. As far as methods to be incorporated I'd recommend LMCF since its heavily alg based ( not sure if this is easier or not tho. Full LMCF is ~800 algs ). Waterman would be a natural extension of LMCF since its basically just a subset of the method. I'd love to see SCC since I main it ( love a bit of bias ). I also know people would like to see ZZ-CT (only need to add addition algs, for the most part, so shouldn't be too hard ). Oh and I know 42 would be highly requested.
 

Silky

Member
Joined
Apr 5, 2020
Messages
873
A quick question. In your program there is a scramble difficulty evaluation. How is this determined?
 

GRVigo

Member
Joined
Jan 29, 2020
Messages
179
Location
Vigo, Spain
A quick question. In your program there is a scramble difficulty evaluation. How is this determined?
The idea is perform a search to see how many sequences solves common structures (as CFOP Cross, Roux blocks, ...) in a few movements (5, 6 or 7). Then I apply a logarithm function to each amount of secuences and I calculate the average, this give me a score.

I generated one million of random scrambles with their scores, and I have the probabilitys distribution. Between the maximum an minimum scores I define a scale.

For example, the current world record scramble [F U2 L2 B2 F' U L2 U R2 D2 L' B L2 B' R2 U2] gives me a 'very easy' score, and the JPerm's hardest scramble [B F U F D R' F D L B2 U' B2 D B' R' F2 L2 R2 U'] gives me a 'very hard' score.

I'm currently rewriting the source code, getting 20% better performance and other improvements.
 
Top