Developing a better LL system

[Kirjava]

I still don't understand you, that's really confusing. It already knows which case is solved?

 

[vcuber13]

I believe he wants to know how you represented each LL case in your program, for example if you used one array for the orientation, and one for permutation.

 

[Kirjava]

[0,1,2,3,0,0,0,0,0,1,2,3,0,0,0,0]

UB UR UF UL EO EO EO EO UBL UBR UFR UFL CO CO CO CO

You can just loop through permutations and orientation to solve entire subsets.

 

[Villyer]

That's what I was looking for, thank you. Sorry for poor explanation.

 

[PhillipEspinoza]

Read the thread beginning to end.

If the whole point of this new system is meant to make a faster LL, why fix something that ain't broke? LL can be solved in an avg of almost 2 seconds these days by top cubers using OLL/PLL and the way Faz solves the LL is pretty much 1LL anyway. Why go through all this trouble because in theory this "sounds nice" and is alternative? I'm all for creating new ideas but if the idea is to create something faster and more efficient than OLL/PLL then I'd say the payoff doesn't seem too promising.

Of course admitting this would be hard because so much work went into it, but it's one of those things, show me, not just the THEORY, because a lot of ideas sound good in theory, but in practice can it really be faster than 2 seconds on avg?

 

[Kirjava]

If the whole point of this new system is meant to make a faster LL, why fix something that ain't broke?

I dislike this misled fallback phrase people seem to enjoy applying.

If something isn't broken, you can continue to use it. That's fine.

However, there is something that exists called improvement. There is nothing wrong with exploring things for improving our existing systems. People have been doing it for years.

If everyone thought like you do from the inception of cubing, development would be massively stagnated and we would be using Minh Thai's corners first method.

LL can be solved in an avg of almost 2 seconds these days by top cubers using OLL/PLL and the way Faz solves the LL is pretty much 1LL anyway. Why go through all this trouble because in theory this "sounds nice" and is alternative? I'm all for creating new ideas but if the idea is to create something faster and more efficient than OLL/PLL then I'd say the payoff doesn't seem too promising.

Are you seriously telling me that we should no longer be attempting to find improvements to our solving methods? If so, I invite you to leave this thread because it's about method development and it is not suitable for you to take part in it.

Of course admitting this would be hard because so much work went into it

Being aware of your shortcomings is very important. Realising convictions you had are mistaken is quite an asset when working on things like this. There's a paragraph on this very thing in my method development primer. If this doesn't work for whatever reason, I will be the first to acknowledge it.

but it's one of those things, show me, not just the THEORY, because a lot of ideas sound good in theory, but in practice can it really be faster than 2 seconds on avg?

Do you not realise that you have to complete the theory stage before something can be put into practise? Do you not realise that this all cannot be done instantly?

 

[Stefan]

LL can be solved in an avg of almost 2 seconds these days by top cubers using OLL/PLL

I'd like to see some statistics to back this up.

[post=922430]According to Brest[/post], Feliks averaged about 2.23 even in his 6.54 world record average. And that was with two OLL "skips" (thanks to OLS) and one EO+ZBLL. Looks like he's not only slower than you say, but is also using stuff other than OLL/PLL (edit: oh wait, does that mean Feliks isn't among those you were talking about?).

 

[supercavitation]

I'd like to see some statistics to back this up.

[post=922430]According to Brest[/post], Feliks averaged about 2.23 even in his 6.54 world record average. And that was with two OLL "skips" (thanks to OLS) and one EO+ZBLL. Looks like he's not only slower than you say, but is also using stuff other than OLL/PLL (edit: oh wait, does that mean Feliks isn't among those you were talking about?).

You forgot the OLLCP/EPLL (sort of different?) on the first solve!

 

[Stefan]

You forgot the OLLCP/EPLL (sort of different?) on the first solve!

No I didn't.

 

[supercavitation]

No I didn't.

My mistake. Are they no different from standard OLL/PLL?

 

[IRNjuggle28]

No I didn't.

Unless you noticed it and intentionally omitted it, you did forget it. You mentioned the two OLL skips (solves 2 and 5) and the EO/ZBLL (solve 4). Not the OLLCP/EPLL. Which happened in solve 1.

My mistake. Are they no different from standard OLL/PLL?

OLLCP happened to be the normal alg that time, but he predicted it, and I know that he at least uses mirrors to force CP skips for that case, if not additional OLLCP algs.

If the whole point of this new system is meant to make a faster LL, why fix something that ain't broke?

That sentence just lost me. It makes no sense. You can't use an analogy like that to refer to solving times, since "broken" and "fixed" are two extremes and solving time is almost exclusively a gray area that's somewhere between "an infinitely long time" and "an infinitely short time." The only broken/fixed comparison that is actually analogous would be "successfully solved" versus "DNF." Otherwise, method times are just varying levels of "broken" and "fixed" with no method falling completely in either category. In the sense that it is theoretically possible to create a LL method faster than OLL/PLL, OLL/PLL is somewhat broken, and should therefore be "fixed" with a better method that is slightly faster, and slightly less "broken." That's the point of method development.

 

[Shiv3r]

There have been a few developments in ideas for LL methods that people have been throwing around. After several discounted ideas and attempts, I've settled on a general system that I think could be good. I've mentioned it to a few people in the past, but I want to finally get it completed.

The general idea is this; a combination of two algs to solve each LL case will be generated from a pool of good/fast algs, so for each LL position an algorithm will be performed to bring the last layer to a position that can be solved from the same pool. So you will never have a bad LL case, since both algs are fast. This is exactly the same as the OLLCP system I am using, and Petrus' 270 ZBLL system. Unlike those two implementations of this technique, no overhead is added from using this - 270 ZBLL is worse than ZBLL alone (assuming the system is fully learnt), but (ignoring issues with recognition and actually learning the system) this should be the best two alg last layer system, as it is technically an implementation of 1LLL. The recognition for the second alg should be better than PLL or ELL, as the cases to recognise are much more distinctive. The recognition for the first appears to be the same as 1LLL recognition on first glance, but I will go into an improvement on that that will also aid learning. Also, the pool of algorithms will likely end up being quite a bit smaller than the total for OLL/PLL, and will essentially be comprised of algorithms you already know. Recognition is the only thing that needs to be learnt.

While the system will be initially two look, the technique used to solve the layer layer in this way is originally intended to be one look, but I am unsure if this is feasable when applied to this large
number of cases. The ability to one look cases should come with practise, but may not.

When I learnt OLLCP, I generated combinations to solve any case and stored them in a table. While this is ok for a small case set like OLLCP (lol), estimated time for learning this system in table form
would be about a year.

I have a program that takes a list of algs and produces a list of every LL case with every possible combination of algs that solves it. This is the method's raw data. It can be used to learn from, but I think it can be made way more learnable.

Here's the current list of algs I'm using;

Spoiler

[qw(1 3 2 0 0 0 0 0 2 3 0 1 1 0 1 1 Sune)],
[qw(3 0 2 1 0 0 0 0 0 1 2 3 2 1 2 1 DoubleSune)],
[qw(0 1 2 3 0 0 0 0 2 3 0 1 0 1 0 2 TripleSune)],
[qw(0 3 2 1 0 0 0 0 0 2 1 3 0 0 0 0 TPerm)],
[qw(0 3 1 2 0 0 1 1 2 3 0 1 1 0 1 1 FatSune)],
[qw(0 2 3 1 0 1 1 0 0 1 2 3 2 1 2 1 DblFatSune)],
[qw(2 3 0 1 0 0 1 1 2 3 0 1 2 0 2 2 RUR2FRF2UF)], # PureSune
[qw(0 1 2 3 0 1 1 0 0 1 2 3 1 1 1 0 LU2L'U'LU'xU2R'U'RU'r')], # PureFat
[qw(2 3 0 1 1 1 1 1 2 3 0 1 2 0 2 2 FURU'R'F'R'F'U'FUR)], # AllSune
[qw(2 3 0 1 0 0 0 0 0 1 2 3 1 1 0 1 R'U2R2UR2URU'RU'R')], # SuneH
[qw(0 3 1 2 0 0 1 1 0 2 3 1 1 1 0 1 L'U2LU2LF'L'F)], # C2
[qw(0 3 1 2 0 0 1 1 2 1 3 0 1 1 0 1 FR'F'RU2RU2R')], # C3
[qw(1 2 0 3 0 1 1 0 1 0 3 2 0 2 1 0 FRUR'U'F')], # FRURUF
[qw(2 0 1 3 1 0 1 0 0 1 2 3 2 2 1 1 FRUR'U'RUR'U'F')], # DblFRURUF
[qw(0 1 2 3 0 0 0 0 3 1 0 2 2 0 0 1 L'R'D2RU2R'D2RU2L)], #Opp3
[qw(1 2 3 0 0 0 0 0 2 0 3 1 1 1 0 1 Niklas)], # RU'L'UR'U'L
[qw(3 1 0 2 0 0 1 1 1 2 0 3 1 1 1 0 rU'r'U'rUr'F'UF)], #WeirdNiklas
[qw(2 3 0 1 1 0 0 1 1 2 0 3 1 1 1 0 RU'R'U'F'U2'FU2RU2R')], # FatNiklas
[qw(0 1 2 3 0 0 0 0 0 2 3 1 0 0 0 0 RB'RF2R'BRF2R2)], # A Perm
[qw(0 3 1 2 0 0 0 0 0 1 2 3 0 0 0 0 M2U'MU2M'U'M2)], # U Perm
[qw(2 3 0 1 0 0 0 0 0 1 2 3 0 0 0 0 M2UM2U2M2UM2)], # H Perm
[qw(1 2 0 3 0 1 1 0 1 3 2 0 0 2 0 1 SexyHammer)], # RUR'U'R'FRF'
[qw(0 1 2 3 0 0 0 0 1 3 2 0 0 2 0 1 rUR'U'r'FRF')], # FatSexyHammer
[qw(3 1 2 0 0 0 1 1 1 0 2 3 2 0 0 1 R'FRUR'U'F'UR)], # HardP
[qw(0 2 3 1 0 0 1 1 1 0 3 2 1 0 0 2 R'U'R'FRF'UR)], # EasyC
[qw(1 0 3 2 1 1 1 1 0 1 2 3 0 0 0 0 r'UM2etc)], # ZFlip
[qw(2 3 0 1 1 1 1 1 0 1 2 3 0 0 0 0 MURUR'U'M2URU'r'U')], # HFlip
[qw(3 1 2 0 1 0 1 0 0 3 2 1 2 0 0 1 R2'U'RFR'UR2U'R'F'R)], # DiagT
[qw(0 3 2 1 0 0 0 0 2 3 1 0 2 1 0 0 FRUR'U'RU'R'U'RUR'F')], # TastyT
[qw(1 2 0 3 0 1 1 0 0 2 3 1 2 0 1 0 FRU'RDR'U2RD'R2'U'F')], # WeirdT
[qw(3 0 1 2 1 0 1 0 2 0 3 1 2 0 0 1 RUR'UF'L'ULFU'RU'R')], # PowerT
[qw(1 3 2 0 1 0 0 1 1 3 2 0 1 0 0 2 L2F2R'FRF2L2U2LF'L')], # CheckU
[qw(0 3 1 2 0 0 1 1 3 0 2 1 1 2 2 1 rUR'URUL'UR'U'LUM)], # RandomH
[qw(0 1 2 3 0 0 0 0 0 1 2 3 0 2 0 1 F'RD2R'FU2F'RD2R'FU2)], # PureL
[qw(0 1 2 3 0 0 0 0 0 3 1 2 0 2 0 1 R2DR'U2RD'R'U2R')], # L3
[qw(1 2 0 3 0 1 1 0 0 3 1 2 2 1 0 0 FR2DR'URD'R2U'F')], # E2
[qw(3 1 0 2 1 0 1 0 0 3 1 2 2 1 0 0 fR2DR'URD'R2U'f')], # FatE2
[qw(2 1 3 0 1 0 1 0 1 2 0 3 0 1 2 0 F'LFL'U'L'UL)], # D5
[qw(2 0 3 1 0 0 0 0 3 1 2 0 1 2 1 2 RU'L'UR'ULUL'UL)], # G5
[qw(0 1 2 3 0 1 0 1 1 0 3 2 1 1 2 2 R'U'RU'R'UF'UFR)], # G6
[qw(1 2 3 0 0 1 0 1 0 2 1 3 1 0 0 2 FRU'R'U'L'U'LULF'L2UL)], # F4
[qw(1 2 0 3 0 1 1 0 2 0 1 3 2 2 1 1 FRUR'U'RF'rUR'U'r')], # H2Opp
[qw(1 2 0 3 0 1 1 0 0 1 2 3 0 0 0 0 RUR'U'M'URU'r')], # ezell A
[qw(3 0 2 1 1 1 0 0 0 1 2 3 0 0 0 0 M'UMU2M'UM)], # ezell 1
[qw(2 1 3 0 0 0 0 0 2 3 0 1 1 1 2 2 Bruno)], # Bruno
[qw(0 2 1 3 0 0 0 0 0 2 1 3 0 0 0 0 JPerm)]

Please offer revisions (tell me which algs are bad and add good ones).

While the combinations for each case may appear to be random at first, reorganisation of the data brings order to this madness.

Instead of learning algs organised by cases, I propose the cases be organised by algs.

So for example, you would click on the Sune page, and see a list of all the cases that are solved with a Sune. You learn all the cases that correspond to each alg.

This still seems difficult, but there are many shortcuts that can be used to improve this.

You don't actually have to learn all the cases to be able to solve them. For example, if a single alg can be used to solve some given CLL case + various 3 cycles of edges, instead of listing all those cases, you can simply list one case with the edge stickers greyed out. This phenomenon isn't rare, and combinations for algs can be chosen in such a way that increases the case reduction oppertunities.

Each list of cases for an alg could be broken down into smaller groups, but as I haven't done the basic organisation yet (algs -> cases), I don't know what exactly will be the best way to present the data to be easily learnt.

The raw data table of all cases is being generated at the moment so I thought I'd write this post for advice on the next stage while I waited Here is an example of the output (ELL) while I will convert to look like something like this once every LL position has been solved. Hopefully tomorrow.

Advice and suggestions for improvements would be greatly appreciated. Mostly in regard to organising the data in a learnable format.

I was going to post this in the private lounge, but thought that there may be people outside of it that could help.

Please do not reply with endless variations on the idea as is the norm with threads like this. They are probably equally valid ideas, but I would like to proceed without changing the spec unless it is an obvious improvement.

lars petrus had an Idea like this for ZBLL's, i might adapt the algs for right-handed people and redo the thing, once I have time.

 

[Shiv3r]

This way of doing it may be a little hard for a 1LLL, but lars petrus's Ideas have some merit.

 

[Teoidus]

Has Kirjava just vanished recently? This looked interesting.

 

[Lars Petrus]

Hey kids!

I've been working on a universal way to make and use these combo alg sets at my LL DB site (http://birdflu.lar5.com). You can pick your own set of base algs¹, it's easy and fun to use, etc.

Except that part isn't public yet. I want to polish it a bit more first, and I could really use a few people willing to test it out, and tell me what's wrong with it and stuff.

Any volunteers?

You'll need a WCA ID.

¹ Some restrictions apply.

 

[Shiv3r]

Hey kids!

I've been working on a universal way to make and use these combo alg sets at my LL DB site (http://birdflu.lar5.com). You can pick your own set of base algs¹, it's easy and fun to use, etc.

Except that part isn't public yet. I want to polish it a bit more first, and I could really use a few people willing to test it out, and tell me what's wrong with it and stuff.

Any volunteers?

You'll need a WCA ID.

¹ Some restrictions apply.

Looks interesting. what do you need me to do? (Im the guy who emailed you last year about how you started into cubing, remember) my WCA ID is 2016LEWI04.

 

[Lars Petrus]

Oh yeah, we even talked about the combo thing!

The ideal tester would build their own combo alg set and try to use it.

I added you to the list of testers. To use it log in (top right), and a new "Combos" section appears top left. It could probably be clearer what to do from there, but it's part of testing to see how hard it is to figure out

Logging in is done through your worldcubeassociation.org account, which I guess you'll have to create if you don't have one.

Being logged in also makes it possible to "star" favorite algs.

 

[Shiv3r]

Oh yeah, we even talked about the combo thing!

The ideal tester would build their own combo alg set and try to use it.

I added you to the list of testers. To use it log in (top right), and a new "Combos" section appears top left. It could probably be clearer what to do from there, but it's part of testing to see how hard it is to figure out

Logging in is done through your worldcubeassociation.org account, which I guess you'll have to create if you don't have one.

Being logged in also makes it possible to "star" favorite algs.

It isn't working for me right now. did you make sure to add 2016LEWI04(Johnathan Lewis) to the list of testers? I cannot log in.
EDIT: I went back and prssed the back button, now I'm logged on.

Also, is there a possible way to select more than one Edge set? I am going to find a set of COLL+ (forcing a U permutation for the second step of COLL-EPLL)algorithms ,and I need to find algs that preserve phasing, which means selecting like 5 EP's.
Can you let users create their own "alg lists" like you would playlists in a music app, that you can share with people and stuff? that may make lots of sense, since its basically building alg sheets. I like the Idea! it will definitely help some people out, I probably will be one of them.
EDIT: whenever I click "show" it lengthens the page, but there is nothing, I scroll down and it's just white space.

 

[Lars Petrus]

You can make public alg lists from your starred/favorite algs. These are my blue star ★ algs for example: http://birdflu.lar5.com/galaxies/2

For now you can only select one specific EP or none. But tell me more about this "phasing" thing, and what you'd need for that.

 

[Shiv3r]

You can make public alg lists from your starred/favorite algs. These are my blue star ★ algs for example: http://birdflu.lar5.com/galaxies/2

For now you can only select one specific EP or none. But tell me more about this "phasing" thing, and what you'd need for that.

Phasing is something ZZ users use(the last steps are very similar to your method, a lot of ZZ variants work with petrus, like Winter variation, CLS, etc.). When inserting the last F2L slot, they force opposite edges to be opposite of each other, which reduces the amount of algorithms needed for a 1look last layer. the 1LLL set with edges phased is called ZZLL, and it has only 71 algorithms to cover about 117 cases, as opposed to full ZBLL's 170 algs to cover ~300 cases.
ZZLL can actually be used with petrus, I believe Tao Yu the fastest petrus user uses ZZLL. recognition during the last slot is simple, it only adds a few moves to LS, and its completely intuitive.

The thing is that that is only one of the ZZ variants, for some reason about 90% of the methods invented nowadays are variants of ZZ.

The reason I want to have edges phased algs are because I am trying to com eup with COLL+ algorithms. COLL+ is where you force unphased edges during COLL by using 2 COLL's for each case, one that preserves phasing and one that breaks phasing. If you get edges unphased while solving COLL(opposite edges are adjacent), then use teh alg that preserves phasing to preserve the unphasingness, and use one that breaks up phasing. in doing this you always force one of the U-perms which are much better than what you would get with edges phased, Zperm or H-perm. but dont use COLL+ if you know youre going to get a skip.