• 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 35,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!

CubeTeacher

Joined
Aug 29, 2007
Messages
837
Likes
16
YouTube
badmephisto
#21
qqwref brings up good points.

also for example moves like B should be disallowed? You can't feasibly, in an actual solve, perform those moves efficiently... stuff like that
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #22
Excellent suggestions and thank you for your input!

Try to focus on keeping the computer to a human-like solving method. That is, use one or two algs per OLL/PLL/F2L case (and maybe allow the user to enter their own alg if they want), and try not to be *too* optimal.
Exactly my thoughts. I thought of having another file for settings for algorithms. Currently the program stores settings in 'Settings.xml', so I might have another settings file called 'Algorithms.xml' that will contain all the algorithms to use for solving. Now the useful thing about this is that you'll be able to have multiple files which you can just replace with the 'Algorithms.xml' when you want to use a different set of algorithms. You could have a 'SimpleAlgs.xml' that you designed with just one algorithms for every situation. Then you could have an 'AdvancedAlgs.xml' with maybe 5 solutions for every single case possible which would find an extremely optimal solution. This is one of the top things on my todo list for this application as it is very practical and should be easy to implement. I may get rid of the options in the solver tab for 'Beginner F2L', 'Beginner OLL', and 'Beginner PLL' so that the user can simply control which algorithms to use instead (eg. 'FridrichAlgs.xml' and 'BeginnerAlgs.xml'). Now don't worry, these .xml files will not require the user to manually input algorithms into the file. There will be a graphical interface for setting up all the algorithms. Perhaps I'll have the program open up a dialog which will show you the list of situations, then you can click on a situation and it will display the situation on the main cube, then you can perform an algorithm to solve the situation, which will be recorded by the application and stored in the algorithms file. As you can see, I love this whole concept of user-defined algorithms.. :D

For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).

Similarly, if your computer is trying to find really nice solutions for the entire F2L at once, try not to do anything that a human wouldn't be able to think of in a solve (like solving three pairs at once with blockbuilding).
Something like blockbuilding is very difficult to implement programmatically as it is all based on reasoning. So I don't think people will have trouble with the computer solving 3 pairs at once.. Maybe one in every 10,000 solves will this happen :cool:

Or you could try not to cancel between steps. I'm assuming here that someone who's just learning to use Fridrich won't be doing movecanceling or multislotting on the fly.
This will be a simple matter to implement as well. I can make a simple setting for not reducing redundant moves in between steps. Good suggestion.

I like the "greyed out" idea, but it might be better to use an only partial grey - what I mean is, instead of just making the pieces completely grey, maybe just make them much darker or greyer but still colored. It's definitely true that people should concentrate on the step they're doing, but it should still be possible to see the other colors to remind them that on a real cube they will be able to (or to allow them to do basic lookahead). I guess a sliding bar thing would be most appropriate here.
I fear that you have not looked through the settings enough. In the settings there is a tab for the solver, then there is a grouping with a caption called 'Phase focus'. This lets you set what color to gray the cubies with, what opacity to use for the actual color of the tile when grayed, and what opacity to use for the graying. Very customizable. Very simple to use. :cool:

For a full-cube solution, if this is reasonable, each step (cross, each F2L pair, OLL, PLL) should be on a new line - keeping the whole thing in one textbox looks kind of cluttered and is hard to read.
Excellent idea. I think I got carried away with my neat idea of a scrolling text box like I implemented. I can get rid of the scrolling and just have a nice text box with highlighting, new lines for each phase of the solution, and text wrapping can be turned on and off. Good suggestion. And if the coloring of the solution text is annoying, it is all customizable in the settings under the solver tab in the grouping labeled 'Phase text highlighting'.

I don't know how your program behaves at the end of the solve, but how about showing the solution and showing you what you did in each part? The program could offer suggestions on how to do the cross and F2Ls more efficiently, so that you could easily see if something needed work (and what to do instead).
I'm not quite sure what you mean by this. The program executes OLL then PLL at the end. It usually gets a skip on one or the other though.

when you go through the solution using arrows, could the moves be animated? Its hard to see what goes on when it snaps into places, especially with the rotations
By the default settings, the moves are actually being performed at 90 degrees per timer cycle. So if you'd like to see the moves performed more slowly I would suggest simply changing the settings for the fast forward speed. In the settings under the solver tab and in the grouping labeled 'General', there is a setting for 'Turn speed (fast forward)'. Simply turn the speed down a few notches and you'll be able to see the rotations more clearly. There is a similar setting under the scrambler tab.

could there be a way to force the cross color?
Absolutely. I hadn't thought of this but it would be excellent if a user preferred a certain color for the cross. Easy to implement. I'll work on this too.

it doesnt look like its doing OLL/PLL, but it doesnt matter too much.
The program actually encounters a lot of OLL skips and PLL skips. I will get around to making a nice dialog for choosing a solve to execute instead of the best solution. There will be a nice summary of each solve so that you can choose whether to use a solve with OLL and PLL skips involved.

I would really like to use this to find better ways of doing the F2L. It would be great if it spewed out F2L solutions, and you could go through all of them and see how they play out or something. but that seems like a lot of work (especially interface ***** work, the one noone ever wants to do)
Like I said, there will be a nice dialog for picking out many different solutions for the same solve. This isn't too much work as the solver already calculates all the solutions. It may take me a while to find a user-friendly interface that displays each solution for the user to pick from.

qqwref brings up good points.

also for example moves like B should be disallowed? You can't feasibly, in an actual solve, perform those moves efficiently... stuff like that
This should be avoidable when I implement user-definable algorithms. The user can decide whether to allow the solver to use B moves.


Overall, excellent suggestions. I have some renewed vigor for this application now from these good ideas and I'll start working on some of these ideas. Please continue to find bugs and give suggestions.
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #24
For forcing cross color, just put the cross color you want on the bottom...I think that works :)
He/she's not talking about forcing cross color for 'User solve mode'. They're talking about the actual solver. Currently, the solver solves the cross on all sides and finds solutions for each. I can easily make a setting to force the solver to omit certain sides for building the cross on.
 
Joined
Dec 6, 2006
Messages
1,142
Likes
3
Location
Rochester, NY
WCA
2008CLAY01
#25
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
I'd say more like 7.25 moves.
 
Joined
Dec 18, 2007
Messages
7,830
Likes
33
Location
a <script> tag near you
WCA
2006GOTT01
YouTube
qqwref2
#26
I don't know how your program behaves at the end of the solve, but how about showing the solution and showing you what you did in each part? The program could offer suggestions on how to do the cross and F2Ls more efficiently, so that you could easily see if something needed work (and what to do instead).
I'm not quite sure what you mean by this. The program executes OLL then PLL at the end. It usually gets a skip on one or the other though.
I was talking about when you do a solve yourself using the heise-style interface. Basically the program should be able to analyze a solve that you do on the simulated cube, and then tell you what to work on.
 

AvGalen

Premium Member
Joined
Jul 6, 2006
Messages
6,857
Likes
87
Location
Rotterdam (actually Capelle aan den IJssel), the N
WCA
2006GALE01
YouTube
arnaudvg
#27
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
I'd say more like 7.25 moves.
For speed, I would say slightly above 7 indeed (http://stefan-pochmann.info/misc/F2Lstudy/, deduct about 6 moves for the cross)

For greedy optimality (doing 1 pair optimal but not caring about the next one) you should look at http://stefan-pochmann.info/hume/
Short summary: Pair1: 5.33, Pair2: 5.48, Pair3: 6.03, Pair4: 6.59

And even humans can do a lot better than the greedy optimality, just look at my FMC solution from this weeks weekly competition that use a cross + 4 pairs approach: U2 F R' U2 L2 D2 F2 D' F' U L2 F2 U2 L2 U R2 B2 U' D2 R2 D2

U R L2 F' B (Cross + save Pair 1)
U2 B' R U' R' (Insert Pair 1, create Pair 2)
B2 U2 B2 U' B (Insert Pair 2, create Pair 4)
D' U L U' L' D (Insert "keyhole" Pair 3, orient edges)
U2 B' U B (Insert Pair 4, permute edges)
B' R' B L' B' R B L (Last 3 corners with an inverted-mirrored OLL that is simply a commutator)
 
Last edited:
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #28
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
I'd say more like 7.25 moves.
For speed, I would say slightly above 7 indeed (http://stefan-pochmann.info/misc/F2Lstudy/, deduct about 6 moves for the cross)

For greedy optimality (doing 1 pair optimal but not caring about the next one) you should look at http://stefan-pochmann.info/hume/
Short summary: Pair1: 5.33, Pair2: 5.48, Pair3: 6.03, Pair4: 6.59

And even humans can do a lot better than the greedy optimality, just look at my FMC solution from this weeks weekly competition that use a cross + 4 pairs approach: U2 F R' U2 L2 D2 F2 D' F' U L2 F2 U2 L2 U R2 B2 U' D2 R2 D2

U R L2 F' B (Cross + save Pair 1)
U2 B' R U' R' (Insert Pair 1, create Pair 2)
B2 U2 B2 U' B (Insert Pair 2, create Pair 4)
D' U L U' L' D (Insert "keyhole" Pair 3, orient edges)
U2 B' U B (Insert Pair 4, permute edges)
B' R' B L' B' R B L (Last 3 corners with an inverted-mirrored OLL that is simply a commutator)
Ok so I think you have 33 moves?

Here's CubeTeacher's solution with the current version 0.9.1 Beta.
Cross: BD2UL2U'B'RB2 (8)
Pair 1: yR'U2R2UR' (5)
Pair 2: yU'R'UR (4)
Pair 3: U'F'U2F (4)
Pair 4: y2URU'R' (4)
OLL: yF'LF'L'F2U2R'FRF' (10)

35 moves. Thats pretty close to your solution length considering the computer doesn't even have to do any reasoning. Not sure why it picked a cross solution that long though... I guess it had the best results with that cross solution..

Alright I'm going to start adding on some of the new features you guys have suggested :D
 

AvGalen

Premium Member
Joined
Jul 6, 2006
Messages
6,857
Likes
87
Location
Rotterdam (actually Capelle aan den IJssel), the N
WCA
2006GALE01
YouTube
arnaudvg
#29
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
I'd say more like 7.25 moves.
For speed, I would say slightly above 7 indeed (http://stefan-pochmann.info/misc/F2Lstudy/, deduct about 6 moves for the cross)

For greedy optimality (doing 1 pair optimal but not caring about the next one) you should look at http://stefan-pochmann.info/hume/
Short summary: Pair1: 5.33, Pair2: 5.48, Pair3: 6.03, Pair4: 6.59

And even humans can do a lot better than the greedy optimality, just look at my FMC solution from this weeks weekly competition that use a cross + 4 pairs approach: U2 F R' U2 L2 D2 F2 D' F' U L2 F2 U2 L2 U R2 B2 U' D2 R2 D2

U R L2 F' B (Cross + save Pair 1)
U2 B' R U' R' (Insert Pair 1, create Pair 2)
B2 U2 B2 U' B (Insert Pair 2, create Pair 4)
D' U L U' L' D (Insert "keyhole" Pair 3, orient edges)
U2 B' U B (Insert Pair 4, permute edges)
B' R' B L' B' R B L (Last 3 corners with an inverted-mirrored OLL that is simply a commutator)
Ok so I think you have 33 moves?

Here's CubeTeacher's solution with the current version 0.9.1 Beta.
Cross: BD2UL2U'B'RB2 (8)
Pair 1: yR'U2R2UR' (5)
Pair 2: yU'R'UR (4)
Pair 3: U'F'U2F (4)
Pair 4: y2URU'R' (4)
OLL: yF'LF'L'F2U2R'FRF' (10)

35 moves. Thats pretty close to your solution length considering the computer doesn't even have to do any reasoning. Not sure why it picked a cross solution that long though... I guess it had the best results with that cross solution..

Alright I'm going to start adding on some of the new features you guys have suggested :D
No, mine is 31 because the end of the 4th pair and the beginning of the last 3 corners cancel perfectly, but for a "human solver" your program is doing very nicely. I heard you mentioning that it gets OLL/PLL skip almost always. Is that because it just tries lots of OLL's, even if they are longer (so it basically just tries to get a 1 look last layer)? Or is it because it chooses a different F2L, if that gives shorter last layers?
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #30
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
I'd say more like 7.25 moves.
For speed, I would say slightly above 7 indeed (http://stefan-pochmann.info/misc/F2Lstudy/, deduct about 6 moves for the cross)

For greedy optimality (doing 1 pair optimal but not caring about the next one) you should look at http://stefan-pochmann.info/hume/
Short summary: Pair1: 5.33, Pair2: 5.48, Pair3: 6.03, Pair4: 6.59

And even humans can do a lot better than the greedy optimality, just look at my FMC solution from this weeks weekly competition that use a cross + 4 pairs approach: U2 F R' U2 L2 D2 F2 D' F' U L2 F2 U2 L2 U R2 B2 U' D2 R2 D2

U R L2 F' B (Cross + save Pair 1)
U2 B' R U' R' (Insert Pair 1, create Pair 2)
B2 U2 B2 U' B (Insert Pair 2, create Pair 4)
D' U L U' L' D (Insert "keyhole" Pair 3, orient edges)
U2 B' U B (Insert Pair 4, permute edges)
B' R' B L' B' R B L (Last 3 corners with an inverted-mirrored OLL that is simply a commutator)
Ok so I think you have 33 moves?

Here's CubeTeacher's solution with the current version 0.9.1 Beta.
Cross: BD2UL2U'B'RB2 (8)
Pair 1: yR'U2R2UR' (5)
Pair 2: yU'R'UR (4)
Pair 3: U'F'U2F (4)
Pair 4: y2URU'R' (4)
OLL: yF'LF'L'F2U2R'FRF' (10)

35 moves. Thats pretty close to your solution length considering the computer doesn't even have to do any reasoning. Not sure why it picked a cross solution that long though... I guess it had the best results with that cross solution..

Alright I'm going to start adding on some of the new features you guys have suggested :D
No, mine is 31 because the end of the 4th pair and the beginning of the last 3 corners cancel perfectly, but for a "human solver" your program is doing very nicely. I heard you mentioning that it gets OLL/PLL skip almost always. Is that because it just tries lots of OLL's, even if they are longer (so it basically just tries to get a 1 look last layer)? Or is it because it chooses a different F2L, if that gives shorter last layers?
It chooses a different F2L, if that yields a shorter total solution length. The main goal is to get the shortest possible total solution, not just get an OLL skip and/or PLL skip.
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #32
Small update made for v0.9.1.3. You can view the version history and download link in the first post made in this thread.

Over the weekend I'll start adding some of the features you guys requested. If any of you have any suggestions on how to rework the settings dialog to be less cluttered and more user-friendly, please let me know.
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #33
Small update made for v0.9.1.4. You can view the version history and download link in the first post made in this thread.

If any of you have any suggestions on how to rework the settings dialog to be less cluttered and more user-friendly, please let me know.
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #34
Large update made for v0.9.1.5. You can view the version history and download link in the first post made in this thread.
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #35
Update made for v0.9.1.6. You can view the version history and download link in the first post made in this thread.

Just curious, who actually uses this program as their primary virtual cube to toy around with?
 
Joined
Mar 19, 2009
Messages
147
Likes
3
Location
Arizona
Thread starter #36
Minor update made for v0.9.1.7. You can view the version history and download link in the first post made in this thread.
 
Top