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

Developing a better LL system

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
Likes
39
WCA
2006BARL01
YouTube
snkenjoi
Thread starter #1
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;

Code:
[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.
 

Dene

Premium Member
Joined
Dec 5, 2007
Messages
6,909
Likes
55
WCA
2009BEAR01
YouTube
masterNZ
#4
Interesting idea, but if I've got it right, trying to organise the mess of algorithms into something ordered would be a mammoth task >.<
 
Joined
Apr 6, 2009
Messages
1,753
Likes
11
Location
Sweden
WCA
2010JERN01
YouTube
jernqvist
#5
Is 1LLL worth it though? I mean ZB produces solution for LS+LL in basically the same move and look count, but at a much lower alg count. ZB 270 plus some edge flipping algs might be good enough, but then again ZB is unproven to be worth it. One can do a lot of clever stuff with LL, especially when the clock isn't ticking, but when it comes to speed; just "braindeading" it is just so fast. It's a real pity that we can turn faster than we can think, so to speak. Maybe feet can become a cool event by these sort of random optimisations. Ok, I'll stop rambling now.
 

Godmil

Premium Member
Joined
Aug 12, 2010
Messages
2,196
Likes
5
Location
Aberdeen, Scotland
YouTube
Godmil
#6
So just to be clear, the system solves the LL only using good algs, from whatever set. So if you had a nice OLL you'd do that, but if it was a bad oll you could do a COLL case followed by a good ELL?
 
Last edited:
Joined
Jan 7, 2011
Messages
1,843
Likes
4
Location
UK
WCA
2011WALL02
YouTube
MLSTRMRVLTN
#7
So just to be clear, the system solves the LL only using good algs, from whatever set. So if you had a nice OLL you'd do that, but if it was a bad oll you could do a COLL case followed by a good ELL?
Not really, I'm pretty sure this system is for 1LLL, but instead of using single algs, he's using combinations of shorter, but fast algs, to create a 2 Alg, 1 Look system.
 

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
Likes
39
WCA
2006BARL01
YouTube
snkenjoi
Thread starter #8
Is 1LLL worth it though? I mean ZB produces solution for LS+LL in basically the same move and look count, but at a much lower alg count.
You seem to have misunderstood. This is intended to be a two look system and is less algs than OLL/PLL.

So just to be clear, the system solves the LL only using good algs, from whatever set. So if you had a nice OLL you'd do that, but if it was a bad oll you could do a COLL case followed by a good ELL?
No, that's completely wrong. This is nothing to do with other LL systems or using other sets.

I *choose* a list of algs I want to use. It will be *less algs* than any other two look last layer system.

For example, a solution for one of the cases is FRUR'U'F' then Sune. This doesn't appear in any other system.

To an outside observer, it will appear as if you have applied two random short algs to solve each LL case.
 

Cubenovice

Forever Slow
Joined
Feb 6, 2010
Messages
2,281
Likes
5
Location
Vlaams-Brabant (Belgium)
#9
**
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.
**
Instead of learning algs organised by cases, I propose the cases be organised by algs.
**
This is intended to be a two look system and is less algs than OLL/PLL.
**
It will be *less algs* than any other two look last layer system.
Let it be clear that I support all types of method development and I am very interested to see where this will lead to

Being a slow OLL / PLL user myself I’m wondering if there are particulary “bad” or “slow” OLL / PLL algs?

As Irontwig already mentioned OLL / PLL is pretty much a braindead method for both recognition and execution.
I think most people will agree that 1LLL recognition is out of bounds.
So I am very interested in your improvement for recognition on which alg to use first. It seems that there is a large gap to bridge.

As far as the number of algs goes:
My initial reaction: cool, just 46 algs to solve LL (against 78 for OLL-PLL)
But from your ELL example it seems that quite a lot of the solutions involve mirrors and inverses.
I can live with mirrors being considered the same alg as far as recognition and execution is concerned.
But inverses are something different so this is possibly adding another 46 algs, still not bad though :)

I like the suggestion of grouping per alg!

I will keep following this thread for sure!
 

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
Likes
39
WCA
2006BARL01
YouTube
snkenjoi
Thread starter #10
Being a slow OLL / PLL user myself I’m wondering if there are particulary “bad” or “slow” OLL / PLL algs?
It depends how you define bad or slow. It doesn't really matter though, because the solution speed and movecount for a given case will *always* be better when compared to OLL/PLL.

As Irontwig already mentioned OLL / PLL is pretty much a braindead method for both recognition and execution.
I think most people will agree that 1LLL recognition is out of bounds.
So I am very interested in your improvement for recognition on which alg to use first. It seems that there is a large gap to bridge.
I think after the gap has been bridged, the braindeadedness will be on par with OLL/PLL.

Recognition isn't really a problem, especially since it won't always be full 1LLL recognition. The problem is with recall. ZBLL has a massive recall problem - however, with a tiny set of algs in use here, I believe recall will be much less of a problem.

As far as the number of algs goes:
My initial reaction: cool, just 46 algs to solve LL (against 78 for OLL-PLL)
But from your ELL example it seems that quite a lot of the solutions involve mirrors and inverses.
I can live with mirrors being considered the same alg as far as recognition and execution is concerned.
But inverses are something different so this is possibly adding another 46 algs, still not bad though :)
It should be less than 46 algs, I am going to attempt to cover all cases with as few as possible.

I don't intend to use inverses and mirrors for all cases - they're just there so I didn't have to add seperate algs for mirrored and inverted sunes or niklases or whatever (which will be the only ones I will use).

I like the suggestion of grouping per alg!
Yeah! Further organisation will have to be done though before this is accessable for the common speedcuber.
 
Joined
Feb 17, 2011
Messages
415
Likes
10
Location
Singapore
#11
Sounds like an good alternative to OLL&PLL, may consider switching to it when the algs are generated =)
But, are you intending to generate various gens of algs or just one?
 

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
Likes
39
WCA
2006BARL01
YouTube
snkenjoi
Thread starter #12
Sounds like an good alternative to OLL&PLL, may consider switching to it when the algs are generated =)
But, are you intending to generate various gens of algs or just one?
People seem to have trouble understanding exactly what this system entails. That's understandable because it isn't straightforward - it should become clear when the learnable version is complete.

Algorithms don't need to be generated.
 

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
Likes
39
WCA
2006BARL01
YouTube
snkenjoi
Thread starter #14
Not exactly true.. you need to generate the combinations :/
True, but this is an automated task, and is entirely different from generating a set of algorithms for any other system.

The actually difficult task that needs to be done is the organisation.
 

Cubenovice

Forever Slow
Joined
Feb 6, 2010
Messages
2,281
Likes
5
Location
Vlaams-Brabant (Belgium)
#17
Yeah! Further organisation will have to be done though before this is accessable for the common speedcuber.
As I'm definitely not a common speedcuber I expect to be granted early acces :)

How about making the "cross-check program" (for lack of a better name...) accessable so people can input their own alg sets?
Not perse with the goal of finding combinations that cover full LL but perhaps there are some nice cases comparable to "FRUR'U'F' then Sune where you can use two short algs to solve LL.

Think of it as the speedsolving equivalent of the list with "LL cases up to 10 moves "used by some of the hardcore FMC -ers.

Ehm?
"FRUR'U'F' then Sune. This doesn't appear in any other system.
Strange, this combination occasionally solves my LL when I"m CFOP-ing????
 
Joined
Oct 29, 2010
Messages
283
Likes
0
Location
Novosibirsk, Russia
WCA
2011OBLA01
YouTube
NSKuber
#18
So, if I'm understanding right, first alg will make whole LL easier(but won't do all orientation or permutation), so it will be quickly finished by another easy alg? If it's true, it's very interesting, I've never thought about something like this before :)
 
Joined
Nov 28, 2009
Messages
1,793
Likes
1
WCA
2010LACH01
YouTube
fatboyxpc
#19
Strange, this combination occasionally solves my LL when I"m CFOP-ing????
I'm under the impression that his point is that there isn't a system out there where those two algs solve a specific LL case that you learn from said system. The difference here is that you can have the same OLL with a different CP where you would still do F R U R' U' F' which gives you a Sune, which then gives you a totally different PLL. In his system, if you had the same OLL with a different CP, you wouldn't do the same 2 alg combination to solve the LL case, whereas you still would (and then have to do PLL).
 
Top