# Developing a better LL system



## Kirjava (May 11, 2012)

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.


----------



## Escher (May 11, 2012)

Once done, this will be awesome.


----------



## AustinReed (May 11, 2012)

Learning this LL method > Doing well in competition. Can't wait to see how good this is going to become.


----------



## Dene (May 11, 2012)

Interesting idea, but if I've got it right, trying to organise the mess of algorithms into something ordered would be a mammoth task >.<


----------



## irontwig (May 11, 2012)

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 (May 11, 2012)

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?


----------



## MaeLSTRoM (May 11, 2012)

Godmil said:


> 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 (May 11, 2012)

irontwig said:


> 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.



Godmil said:


> 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 (May 11, 2012)

Kirjava said:


> **
> 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.
> ...


 
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 (May 11, 2012)

Cubenovice said:


> 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. 



Cubenovice said:


> 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.



Cubenovice said:


> 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).



Cubenovice said:


> 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.


----------



## Genesis (May 11, 2012)

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 (May 11, 2012)

Genesis said:


> 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.


----------



## joey (May 11, 2012)

Not exactly true.. you need to generate the combinations :/


----------



## Kirjava (May 11, 2012)

joey said:


> 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.


----------



## mati1242 (May 11, 2012)

I'm really looking forward to see how this method will performs.


----------



## joey (May 11, 2012)

Kirjava said:


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



I put my trust in you.


----------



## Cubenovice (May 11, 2012)

Kirjava said:


> 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????


----------



## NSKuber (May 11, 2012)

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


----------



## FatBoyXPC (May 11, 2012)

Cubenovice said:


> 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).


----------



## Divineskulls (May 11, 2012)

Reduction LL? Sounds promising.  I'm looking forward to it in its completed form.


----------



## Kirjava (May 11, 2012)

joey said:


> I put my trust in you.



<3



Cubenovice said:


> As I'm definitely *not* a common speedcuber I expect to be granted early acces



I intend to make the data available to everyone. When I said not accessable to the common cuber yet, I meant that it might be too hard for them to understand or learn until the organised version has been completed.



Cubenovice said:


> How about making the "cross-check program" (for lack of a better name...) accessable so people can input their own alg sets?



Maybe, but if they have their own alg sets they think are better they should contribute them to the project! This should really be done before work is started on the next part. I don't mind sharing the solver but unsure what use it would be to people outside of this kind of use.



Cubenovice said:


> *"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????


 
fatboyxpc pretty much explained what I meant. A better example would be that one of the last layer cases will be T Perm then Sune


----------



## jeff081692 (May 11, 2012)

I'm pretty excited for this. Just got on summer vacation so I can devote an insane amount of time into learning it.


----------



## cemoss (May 11, 2012)

waiting for it to come!


----------



## Thunderbolt (May 11, 2012)

Sorry guys but I have no idea what is this. Could someone explain this to me. I see only list of algs but I don't see how to recognize the cases wtf


----------



## MostEd (May 11, 2012)

Thunderbolt said:


> Sorry guys but I have no idea what is this. Could someone explain this to me. I see only list of algs but I don't see how to recognize the cases wtf


 There are common algs, such as sune, niklas, FRUR'U'F' etc.. 
This method uses those algs to solve the LL and theres 2 algs(2 different ones) per case, you do one then another one

and you recognise by recognising


----------



## Noahaha (May 11, 2012)

I may learn this since I used to use Petrus's one look two algorithm COLL.


----------



## ncube (May 11, 2012)

Kirjava, could you give some examples on a few ll cases to demonstrate recognition with the two algs? Thx


----------



## zzomtceo (May 11, 2012)

Theoretically, with more algs couldn't this be a method for the whole solve?


----------



## Kirjava (May 12, 2012)

Small update - 

Solving the cases is taking longer than I though (my computer isn't that good). So far 3/48 of the table is complete.


----------



## yoinneroid (May 12, 2012)

For those wondering how this works, this site should help


----------



## bobthegiraffemonkey (May 12, 2012)

I never thought this kind of thing would be feasible, but if there's anyone who is crazy, awesome and creative enough to make it work, it's you.

Will this work well for LL subsets do you think? Eg. using this just for COLL cases? I know it would miss the point a little, but I'm curious. And yes, I am seriously considering doing that, at least for 'bad' COLL cases.


----------



## Kirjava (May 12, 2012)

Haha, while working on this I discovered the most horrific LL case I've ever seen.







Optimal solution is; F R D2 F' R2 U B' R2 B U' R2 F D2 R' F' (15f) (<+Brest> [F R D2 F' R2 U B': R2] cute)



bobthegiraffemonkey said:


> Will this work well for LL subsets do you think? Eg. using this just for COLL cases? I know it would miss the point a little, but I'm curious. And yes, I am seriously considering doing that, at least for 'bad' COLL cases.


 
Sure, he basic idea is what I used to learn OLLCP.


----------



## ncube (May 12, 2012)

R2 U2 R' U2 y L' U2 L R U2 R' U2 F U2 F2, Same case, but 14 turns...
Also, for the Mirror, I found 
r’ U2 R U x R’2 U2 R U2 R’ U2 x’ R2 U’ R’ U2 r, which flows nicely.


----------



## ~Adam~ (May 12, 2012)

Seems like a good idea but recognition sounds horrific.


----------



## Kirjava (May 12, 2012)

ncube said:


> R2 U2 R' U2 y L' U2 L R U2 R' U2 F U2 F2, Same case, but 14 turns...
> Also, for the Mirror, I found
> r’ U2 R U x R’2 U2 R U2 R’ U2 x’ R2 U’ R’ U2 r, which flows nicely.


 
That's a different case, the optimal solution for the case I listed is 15 moves.

Also, due to the nature of the system I can't actually use any of those algs.


----------



## aronpm (May 12, 2012)

Kirjava said:


> Small update -
> 
> Solving the cases is taking longer than I though (my computer isn't that good). So far 3/48 of the table is complete.


 
Update:
Running the solver on my machine, it's almost 3/48ths done (it's running about twice as fast as for Kir, and the output is already 400kb ). Raw table should be generated in about 24 hours, then Kir has to organise it. And stuff.


----------



## bamilan (May 12, 2012)

Comparing OLL and your algorithms, they take ~ the same time to execute, but recog of OLL is better.
PLL algorithms are speed optimized, they can be done sub-2. Most of the algorithms in your list take at least 1-1.5 seconds to execute, so the time you can cut using that system is somewhere <0.5 sec in my opinion (assuming that recog for PLL is the same as recog for 2nd algorithm).
Does it really worth to learn?


----------



## Godmil (May 12, 2012)

Ok I think I get it now. It's a really interesting/creative idea. However, due to recog/recoll issues I can't see it being faster than OLL/PLL. But I'm so impressed that you came up with it. Much cooler than all those new LS systems.


----------



## LarsN (May 12, 2012)

Kirjava said:


> Haha, while working on this I discovered the most horrific LL case I've ever seen.
> 
> 
> 
> ...



What is the solution with this new system then?

EDIT: just ran it through your list but didn't find a solution. Most likely a fail on my side though


----------



## Robert-Y (May 12, 2012)

[01:19.53] <Athefre> Shortest CE gives is: F R D2 F' R2 U B' R2 B U' R2 F D2 R' F'
[01:20.04] <Kirjava> is that optimal?
[01:20.08] <Athefre> 15
[01:20.11] <Kirjava> hah.
[01:20.14] <Kirjava> also
[01:20.16] <Kirjava> fuuuuu
[01:20.29] <RobertY> wow this case is so evil
[01:20.34] <Kirjava> yeah
[01:20.37] <Kirjava> there's *nothing*
[01:20.50] <RobertY> no matter what your LL system is
[01:20.55] <RobertY> even 1LLL sucks XD
...
[01:35.16] <RobertY> Kirjava: all I'm doing is trying out random short diag OLLCP algs, then hoping that the resulting OLLCP alg will skip EPLL upon execution
...
[01:36.01] <RobertY> I like this:
[01:36.02] <RobertY> ,i (R U R B' R' B U' R') (R' F R F' R' F R F' R U R' U' R U R')
[01:36.03] <Nibblr> inverse: R U' R' U R U' R' F R' F' R F R' F' R R U B' R B R' U' R'

My best is 1.7x with (R U' R' U R U' R' F R' F' R F R' F' R) (R U B' R B R' U' R')

Anyone think they can find a better alg and beat this?


----------



## Noahaha (May 12, 2012)

A lot of LL situations are just a 3-cycle of corners and a 3-cycle of edges. It would only be like 20 algs to give a lot of 2-alg 1LLLs.

EDIT: 12 edge cycles and 12 corner cycles, and not too bad algs either.


----------



## Cubenovice (May 14, 2012)

Wondering if the calculations have finished?
I will not ask for the organising part (yet)


----------



## aronpm (May 14, 2012)

Cubenovice said:


> Wondering if the calculations have finished?
> I will not ask for the organising part (yet)


 
yep, I've sent them back, but Kir has been partying hard


----------



## FatBoyXPC (May 14, 2012)

Kirjava: Your T-Perm Sune example, is there any reason why one wouldn't use one of the standard COLL cases for that? I don't know COLL so my only guess is that it's a bad COLL case if you'd rather use your example (or unless it was just an example to show 2 common algs in a different order than one would normally use in CFOP).


----------



## Kirjava (May 15, 2012)

Table is complete! Thanks to aron for running the program and dan for converting the position matricies into LL images for me.

*raw table* (essentially unlearnable in current format)

Next job is to organise this stuff. Gonna take me quite a while on my own, but I'll see if I can get people to help once I've got the ball rolling.

Here's the solver incase anyone is interested; (thanks to jlaire for helping me refactor)



Spoiler





```
#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';

print "LL Solver\n\n";

# UBL & UB
# EP EP EP EP EO EO EO EO CP CP CP CP CO CO CO CO
# orientations applied after permutations	

# input

my $mode = 0; # 0 = everything, 4 = OLLCP, 8 = CLL
my @case = qw(0 1 2 3 0 0 0 0 0 1 2 3 0 0 0 0);
my @solved1 = qw(0 1 2 3 0 0 0 0 0 1 2 3 0 0 0 0);
my @solved2 = qw(3 0 1 2 0 0 0 0 3 0 1 2 0 0 0 0); # U
my @solved3 = qw(1 2 3 0 0 0 0 0 1 2 3 0 0 0 0 0); # U'
my @solved4 = qw(2 3 0 1 0 0 0 0 2 3 0 1 0 0 0 0); # U2

my @basealgs =  ( 
[qw(0 1 2 3 0 0 0 0 0 1 2 3 0 0 0 0), ''],
[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 APerm)], # A Perm
[qw(0 3 1 2 0 0 0 0 0 1 2 3 0 0 0 0 UPerm)], # U Perm
[qw(2 3 0 1 0 0 0 0 0 1 2 3 0 0 0 0 HPerm)], # 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(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 3 1 0 0 1 1 1 0 3 2 1 0 0 2 R'U'R'FRF'UR)], # BrestAlg
[qw(0 2 1 3 0 0 0 0 0 2 1 3 0 0 0 0 JPerm)]
);

my @eplookup =  ( 
[qw(0 1 2 3 0 1 2 3)],[qw(0 1 3 2 0 2 1 3)],[qw(0 3 1 2 0 2 3 1)],[qw(3 0 1 2 1 2 3 0)],[qw(0 2 1 3 0 1 3 2)],[qw(0 2 3 1 0 3 1 2)],[qw(0 3 2 1 0 3 2 1)],[qw(3 0 2 1 1 3 2 0)],
[qw(2 0 1 3 2 1 3 0)],[qw(2 0 3 1 2 3 1 0)],[qw(2 3 0 1 2 3 0 1)],[qw(3 2 0 1 1 3 0 2)],[qw(1 0 2 3 3 1 2 0)],[qw(1 0 3 2 3 2 1 0)],[qw(1 3 0 2 3 2 0 1)],[qw(3 1 0 2 1 2 0 3)],
[qw(1 2 0 3 3 1 0 2)],[qw(1 2 3 0 3 0 1 2)],[qw(1 3 2 0 3 0 2 1)],[qw(3 1 2 0 1 0 2 3)],[qw(2 1 0 3 2 1 0 3)],[qw(2 1 3 0 2 0 1 3)],[qw(2 3 1 0 2 0 3 1)],[qw(3 2 1 0 1 0 3 2)]
);

my @cplookup =  ( 
[qw(0 1 2 3 0 1 2 3)],[qw(0 1 3 2 0 1 3 2)],[qw(0 3 1 2 2 1 3 0)],[qw(3 0 1 2 1 2 3 0)],[qw(0 2 1 3 3 1 2 0)],[qw(0 2 3 1 3 1 0 2)],[qw(0 3 2 1 2 1 0 3)],[qw(3 0 2 1 1 2 0 3)],
[qw(2 0 1 3 1 3 2 0)],[qw(2 0 3 1 1 3 0 2)],[qw(2 3 0 1 2 3 0 1)],[qw(3 2 0 1 3 2 0 1)],[qw(1 0 2 3 1 0 2 3)],[qw(1 0 3 2 1 0 3 2)],[qw(1 3 0 2 2 0 3 1)],[qw(3 1 0 2 0 2 3 1)],
[qw(1 2 0 3 3 0 2 1)],[qw(1 2 3 0 3 0 1 2)],[qw(1 3 2 0 2 0 1 3)],[qw(3 1 2 0 0 2 1 3)],[qw(2 1 0 3 0 3 2 1)],[qw(2 1 3 0 0 3 1 2)],[qw(2 3 1 0 2 3 1 0)],[qw(3 2 1 0 3 2 1 0)]
);

my @colookup =  ( 
[qw(0 0 0 0 0 0 0 0)],[qw(0 1 1 1 2 0 2 2)],[qw(1 0 1 1 0 2 2 2)],[qw(1 1 0 1 2 2 2 0)],[qw(1 1 1 0 2 2 0 2)],[qw(2 2 2 0 1 1 0 1)],[qw(0 2 2 2 1 0 1 1)],[qw(2 0 2 2 0 1 1 1)],
[qw(2 2 0 2 1 1 1 0)],[qw(1 0 2 0 0 2 0 1)],[qw(0 1 0 2 2 0 1 0)],[qw(2 0 1 0 0 1 0 2)],[qw(0 2 0 1 1 0 2 0)],[qw(2 1 0 0 2 1 0 0)],[qw(0 2 1 0 1 0 0 2)],[qw(0 0 2 1 0 0 2 1)],
[qw(1 0 0 2 0 2 1 0)],[qw(1 2 0 0 1 2 0 0)],[qw(0 1 2 0 2 0 0 1)],[qw(0 0 1 2 0 0 1 2)],[qw(2 0 0 1 0 1 2 0)],[qw(1 1 2 2 2 2 1 1)],[qw(2 1 1 2 2 1 1 2)],[qw(2 2 1 1 1 1 2 2)],
[qw(1 2 2 1 1 2 2 1)],[qw(1 2 1 2 1 2 1 2)],[qw(2 1 2 1 2 1 2 1)]
);

my @ilookup =  ( 
[qw(0 1 2 3 0 1 2 3)],[qw(0 1 3 2 0 1 3 2)],[qw(0 3 1 2 0 2 3 1)],[qw(3 0 1 2 1 2 3 0)],[qw(0 2 1 3 0 2 1 3)],[qw(0 2 3 1 0 3 1 2)],[qw(0 3 2 1 0 3 2 1)],[qw(3 0 2 1 1 3 2 0)],
[qw(2 0 1 3 1 2 0 3)],[qw(2 0 3 1 1 3 0 2)],[qw(2 3 0 1 2 3 0 1)],[qw(3 2 0 1 2 3 1 0)],[qw(1 0 2 3 1 0 2 3)],[qw(1 0 3 2 1 0 3 2)],[qw(1 3 0 2 2 0 3 1)],[qw(3 1 0 2 2 1 3 0)],
[qw(1 2 0 3 2 0 1 3)],[qw(1 2 3 0 3 0 1 2)],[qw(1 3 2 0 3 0 2 1)],[qw(3 1 2 0 3 1 2 0)],[qw(2 1 0 3 2 1 0 3)],[qw(2 1 3 0 3 1 0 2)],[qw(2 3 1 0 2 3 1 0)],[qw(3 2 1 0 3 2 1 0)]
);

sub mirror($) {
	my ($alg) = @_;
	my @stuff = @$alg;

	my @buf;

	# EP
	for (0 .. 23) {
		if ($eplookup[$_][0] == $stuff[0] && $eplookup[$_][1] == $stuff[1] && $eplookup[$_][2] == $stuff[2] && $eplookup[$_][3] == $stuff[3]) {
			@buf[0 .. 3] = @{$eplookup[$_]}[4 .. 7];
			last;
		} 
		if ($_ == 23) {
			die "wrong EP or something\n";
		}
	}

	# EO
	@buf[4 .. 7] = @stuff[4,7,6,5];

	# CP
	for (0 .. 23) {
		if ($cplookup[$_][0] == $stuff[8] && $cplookup[$_][1] == $stuff[9] && $cplookup[$_][2] == $stuff[10] && $cplookup[$_][3] == $stuff[11]) {
			@buf[8 .. 11] = @{$cplookup[$_]}[4 .. 7];
			last;
		} 
		if ($_ == 23) {
			die "wrong CP or something\n";
		}
	}

	#CO
	for (0 .. 26) {
		if ($colookup[$_][0] == $stuff[12] && $colookup[$_][1] == $stuff[13] && $colookup[$_][2] == $stuff[14] && $colookup[$_][3] == $stuff[15]) {
			@buf[12 .. 15] = @{$colookup[$_]}[4 .. 7];
			last;
		} 
		if ($_ == 26) {
			die "wrong CO or something\n";
		}
	}

	$buf[16] = "Mrr($stuff[16])";

	return \@buf;
}

sub inverse($) {
	my ($alg) = @_;
	my @stuff = @$alg;

	my @buf;

	# EP
	for (0 .. 23) {
		if ($ilookup[$_][0] == $stuff[0] && $ilookup[$_][1] == $stuff[1] && $ilookup[$_][2] == $stuff[2] && $ilookup[$_][3] == $stuff[3]) {
			@buf[0 .. 3] = @{$ilookup[$_]}[4 .. 7];
			last;
		} 
		if ($_ == 23) {
			die "wrong EP or something\n";
		}
	}
	
	#EO
	@buf[4 .. 7] = (0,0,0,0);
	
	for (0 .. 3) {
		if ($stuff[$_ + 4]) {
			$buf[$stuff[$_] + 4] = 1; 
		} 
	}
	# CP
	for (0 .. 23) {
		if ($ilookup[$_][0] == $stuff[8] && $ilookup[$_][1] == $stuff[9] && $ilookup[$_][2] == $stuff[10] && $ilookup[$_][3] == $stuff[11]) {
			@buf[8 .. 11] = @{$ilookup[$_]}[4 .. 7];
			last;
		} 
		if ($_ == 23) {
			die "wrong EP or something\n";
		}
	}
	
	#CO
	@buf[12 .. 15] = (0,0,0,0);
	
	for (0 .. 3) {
		$buf[$stuff[$_+8]+12] = (3 - $stuff[$_+12]) % 3;
	}
	
	$buf[16] = "Inv($stuff[16])";
	
	return \@buf;
}

sub do_y($) {
	my ($pos) = @_;
	my @y;
	my @rebase = (3,0,1,2);
	for (0 .. 3) {
		my $base = $_ * 4;
		if ($_ == 0 || $_ == 2) {
			@y[$base .. $base+3] = map $rebase[$_], @{$pos}[$base+3, $base+0, $base+1, $base+2];
		}
		else {
			@y[$base .. $base+3] = @{$pos}[$base+3, $base+0, $base+1, $base+2];
		}
	}
	\@y;
}

sub add_alg($$) {
	my ($old, $new) = @_;
	#print "add_alg(@$old, @$new)\n";
	for (0 .. 3) {
		my $old_key = join " ", @{$old}[0 .. 15];
		my $new_key = join " ", @{$new}[0 .. 15];
		#print "$old_key <> $new_key\n";
		if ($old_key eq $new_key) {
			#print "SAEM!\n";
			return;
		}
		$old = do_y($old);
	}
	#print "DIFFURENT\n";
	push @basealgs, $new;
}

#Populate database with mirrors and inverses
my $orig_algs = @basealgs;
for (0 .. $orig_algs - 1) {
	add_alg($basealgs[$_], mirror($basealgs[$_]));
	add_alg($basealgs[$_], inverse($basealgs[$_]));
	add_alg($basealgs[$_], inverse(mirror($basealgs[$_])));
}

#Show array (debug)
#for $aref ( @basealgs ) {
#print "\t [@$aref],\n";
#}
#print "\n\n";

sub solved($) {
	my ($position) = @_;
	for my $solved (\@solved1, \@solved2, \@solved3, \@solved4) {
		my $equal = 1;
		for ($mode .. @$position - 1) {
			if ($position->[$_] != $solved->[$_]) {
				$equal = 0;
				last;
			}
		}
		if ($equal) {
			return 1;
		}
	}
	return 0;
}

sub domove($$) {
	my ($position, $alg) = @_;
	my @buf;
	# EP
	for (0 .. 3) {
		$buf[$_] = $position->[$alg->[$_]];
		$buf[$_+4] = $position->[$alg->[$_]+4]; #EO
	}
	# EO
	for (4 .. 7) {
		if ($alg->[$_]) {
			$buf[$_] = 1 - $buf[$_];
		}
	}
	# CP
	for (8 .. 11) {
		$buf[$_] = $position->[$alg->[$_]+8];
		$buf[$_+4] = $position->[$alg->[$_]+12]; #CO
	}
	# CO
	for (12 .. 15) {
		if ($alg->[$_]) {
			$buf[$_] = ($buf[$_] + $alg->[$_]) % 3;
		}
	}
	return @buf;
}

sub solve() {
	
	print "<td><script>ll(\"@case\");</script><br>";

	for my $auf1 (0 .. 3) {
		my $str_auf1 = ("", "U ", "U' ", "U2 ")[$auf1];
		my $alg_auf1 = (\@solved1, \@solved2, \@solved3, \@solved4)[$auf1];
		my @case1 = domove(\@case, $alg_auf1);
	
		if (solved(\@case)) {
			print "&gt; <br>";
			last;
		}

		for my $alg1 (1 .. $#basealgs) {
			my @case2 = domove(\@case1, $basealgs[$alg1]);
			if (solved(\@case2)) {
				print "&gt; $str_auf1$basealgs[$alg1][16]<br>";
				next;
			}
			for my $auf2 (0 .. 3) {
				my $str_auf2 = ("", "U ", "U' ", "U2 ")[$auf2];
				my $alg_auf2 = (\@solved1, \@solved2, \@solved3, \@solved4)[$auf2];
				my @case3 = domove(\@case2, $alg_auf2);

				for my $alg2 (1 .. $#basealgs) {
					my @case4 = domove(\@case3, $basealgs[$alg2]);
					if (solved(\@case4)) {
						print "&gt; $str_auf1$basealgs[$alg1][16] $str_auf2$basealgs[$alg2][16]<br>";
					}
				}
			}
		}
	}

	print "</td>\n";

}

my @ellp = qw(0 1 2 3 2 3 0 1 3 2 1 0 1 0 3 2 0 2 3 1 2 1 3 0 1 3 2 0 1 2 0 3 0 3 1 2 3 1 0 2 3 0 2 1 2 0 1 3);
my @ello = qw(0 0 0 0 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0 1 1 0 1 0 0 1 0 1 1 1 1 1);
my @cllo = qw(0 2 2 2 1 0 1 1 0 1 0 2 2 1 0 0 1 2 0 0 1 1 2 2 1 2 1 2);
my @cllp = qw(0 1 2 3 2 0 1 3 2 1 3 0 3 1 0 2 3 0 2 1 3 2 1 0);


for (my $co=0;$co<7;$co++){
	$case[12] = $cllo[($co*4)];
	$case[13] = $cllo[($co*4)+1];
	$case[14] = $cllo[($co*4)+2];
	$case[15] = $cllo[($co*4)+3];
	for (my $cp=0;$cp<6;$cp++){
		$case[8] = $cllp[($cp*4)];
		$case[9] = $cllp[($cp*4)+1];
		$case[10] = $cllp[($cp*4)+2];
		$case[11] = $cllp[($cp*4)+3];
		print "<tr>\n";
		for (my $eo=0;$eo<8;$eo++){
			$case[4] = $ello[($eo*4)];
			$case[5] = $ello[($eo*4)+1];
			$case[6] = $ello[($eo*4)+2];
			$case[7] = $ello[($eo*4)+3];
			for (my $ep=0;$ep<12;$ep++){
				$case[0] = $ellp[($ep*4)];
				$case[1] = $ellp[($ep*4)+1];
				$case[2] = $ellp[($ep*4)+2];
				$case[3] = $ellp[($ep*4)+3];
				solve();
				#print "<td><script>ll(\"@case\");</script></td>\n";	
				#print @case;print "\n";
				}
		}
		print "</tr>\n";
	}
}

print "\nEnd\n";
```






bamilan said:


> Comparing OLL and your algorithms, they take ~ the same time to execute, but recog of OLL is better.
> PLL algorithms are speed optimized, they can be done sub-2. Most of the algorithms in your list take at least 1-1.5 seconds to execute, so the time you can cut using that system is somewhere <0.5 sec in my opinion (assuming that recog for PLL is the same as recog for 2nd algorithm).



Your complaint is against the algorithms and not the system. I requested that everyone told me which algorithms they thought were not fast and suggested improvements to the list. Most if not all of those algs are sub1.

Second step recog is better than PLL. You don't know what first step recog is yet.

What you're missing (it's been not explicitly stated) is that good case distribution for this system is much much better.

Recog appears to be the only major concern, yet recog is easy and recall is actually the difficult part 



LarsN said:


> What is the solution with this new system then?
> 
> EDIT: just ran it through your list but didn't find a solution. Most likely a fail on my side though


 
No, you're right. It's actually unsolvable with this system. 

There are around 10 cases like this. I'm thinking of either just generating algs for them for 1LLL when it comes up or doing some other thing (I have a few ideas). The probability of each appearing is 1/~4600, so not a huge deal at the moment.



aronpm said:


> yep, I've sent them back, but Kir has been partying hard



<3



fatboyxpc said:


> Kirjava: Your T-Perm Sune example, is there any reason why one wouldn't use one of the standard COLL cases for that?



Because doing TPerm then Sune is better than doing COLL then EPLL?


----------



## MaeLSTRoM (May 15, 2012)

OWOW that is awesome.
I'll help with the recog stuff if you like. This is gonna be fun


----------



## A Leman (May 15, 2012)

I saw this thread a while ago but had my doubts(like how to get my head around it and the probability that you would follow through so fast) about it untill you put up the raw table. It is a very interesting idea. I will defidently put some time into your idea to help make it a method. Thanks kir, I was getting bored with all of the LS suggestions lately.


----------



## StachuK1992 (May 15, 2012)

This is the coolest thing I've seen here in at least a year.


----------



## Kirjava (May 15, 2012)

MaeLSTRoM made an image of the 'evil' cases;







Some are the same, I think he circled mirrors or something idk.


----------



## bobthegiraffemonkey (May 16, 2012)

Kirjava said:


> Setup: F R D2 F' R2 U B' R2 B U' R2 F D2 R' F' U


 
(R' l' U2 L U L' U2 R U' l') U (l' F2 x r' U' r U2 l' U R' U' l')

=OLLCP for adj corners and edge 2-flip + setup to J-perm. Not too bad, gonna keep looking maybe for the hell of it.

I know I'm late, but inverse of my first alg there is pretty nice, so is r' U r2 U' r2' U' r2 U r' plus mirror.

Edit: row 2, case 4: (U2) (F R' F' R U R U' R') U' ( (l R) U R' F' R U R' U' R' F R2 U' R' U' l')
More: SexyHammer [R f R' F': SexyHammer] = R U R' U' R' F R F' R f R' F' R U R' U' l' U R2 u' R'


----------



## Pyjam (May 16, 2012)

What is your idea for case recognition and the choice of the first algorithm?

I believe that you need to know where to go with the first algorithm. In this case, it becomes a 1-LLL.


----------



## Godmil (May 16, 2012)

Just had a look at the raw data... All those algs don't represent different cases do they? Like would you have to memorise them all?
I'm just not seeing how this could be humanly possible (well, maybe if someone was totally hardcore, but the recollection time would be immense).
Hope to be proven wrong though.


----------



## MaeLSTRoM (May 16, 2012)

Godmil said:


> Just had a look at the raw data... All those algs don't represent different cases do they? Like would you have to memorise them all?
> I'm just not seeing how this could be humanly possible (well, maybe if someone was totally hardcore, but the recollection time would be immense).
> Hope to be proven wrong though.


 
in each box is different algs for one case. THe recog system is being worked on, it's gonna take some time.


----------



## LarsN (May 16, 2012)

I guess you may have noticed, but a lot of the algs can easily be removed because of double instances, like:

Sune - Jperm
Sune - inv(Jperm)

or

some alg - Hperm
some alg - U Hperm
some alg - U' Hperm
some alg - U2 Hperm

I wonder which alg for the first "step" is most commonly used ...


----------



## Kirjava (May 17, 2012)

Pyjam said:


> What is your idea for case recognition and the choice of the first algorithm?
> 
> I believe that you need to know where to go with the first algorithm. In this case, it becomes a 1-LLL.



I'm not exactly sure what you mean by your second statement, but I've started working on the case recognition side of things. A surprising amount of cases start with the same algorithm - Sune covers a *lot* of cases.

Still unsure if I should assume people know PLL etc. or not and just have it in a seperate section instead of included with the other cases. Advice on this would be good.



Godmil said:


> Just had a look at the raw data... All those algs don't represent different cases do they? Like would you have to memorise them all?



Lol, nooo. Each case only needs one solution, and the number of cases you need to memorise will end up being quite a bit smaller than the number of actual LL cases.



LarsN said:


> I guess you may have noticed, but a lot of the algs can easily be removed because of double instances, like:



Yeah, I just didn't incorporate the removal of things like that in the solver. Some duplication was removed, but not all of it.


----------



## Godmil (May 17, 2012)

Kirjava said:


> Lol, nooo. Each case only needs one solution, and the number of cases you need to memorise will end up being quite a bit smaller than the number of actual LL cases.



*Phew,
So how many cases roughly do you think people will need to memorise?


----------



## LarsN (May 18, 2012)

Kirjava said:


> Still unsure if I should assume people know PLL etc. or not and just have it in a seperate section instead of included with the other cases. Advice on this would be good.


My opinion is that it is safe to assume that most people looking at this LL approach also knows PLL. On the other hand, including the PLL cases doesn't seem like much of a difference compared to the number of total cases.




Kirjava said:


> ... and the number of cases you need to memorise will end up being quite a bit smaller than the number of actual LL cases.


 
This I don't understand. Aren't you supposed to be able to recognize all LL cases and then decide which alg to start with?
How far are you in the process of finding a good recognition system?


----------



## Kirjava (May 18, 2012)

Godmil said:


> So how many cases roughly do you think people will need to memorise?



I have no idea until it's done really.



LarsN said:


> My opinion is that it is safe to assume that most people looking at this LL approach also knows PLL. On the other hand, including the PLL cases doesn't seem like much of a difference compared to the number of total cases.



I thought that, but then is it safe to assume people know ELL? L3C? 

I wanted to have a seperate section for 'cases you should know' or something, but people who know them can just 1LLL then when they come up anyway. Including them as normal won't really cause a problem, and is a good idea if (/when) people start learning this instead of OLL/PLL.



LarsN said:


> This I don't understand. Aren't you supposed to be able to recognize all LL cases and then decide which alg to start with?



Sort of. For many cases you will be recognising the specific LL case, but since some similar cases will start with the same alg you are able to ignore a large amount of stickers on them, and only have to learn recognition for one of them to cover them all.

I think it'll be clearer once a significant portion is documented. For me too, since the major shortcuts won't appear until I can see the patterns that crop up and can be taken advantage of.



LarsN said:


> How far are you in the process of finding a good recognition system?


 
Dunno until it's finished. Recognition will be different depending on the case.


As far as documentation goes, the data so far seems interesting. Turns out that a significant portion of cases will start with the same alg, which should mean that the number of subsets will be small. No idea if that will make it easy to learn. I think the data will be constantly reorganised to make it easier even after it's 'finished'.


----------



## kashyap7x (May 20, 2012)

Would this get much easier if edges were pre-oriented?


----------



## Escher (May 20, 2012)

kashyap7x said:


> Would this get much easier if edges were pre-oriented?


 
You mean, ZBLL? I actually think in general edges oriented cases will be worse than the rest of the set.

Although I think after finishing this (huge) task it would be cool for the community to help Kir generate and optimise a set of algs for ZBLL


----------



## Pyjam (May 20, 2012)

kashyap7x said:


> Would this get much easier if edges were pre-oriented?


OCLL + PLL is good enough for 2LLL with pre-oriented edges, isn't it?


----------



## kashyap7x (May 20, 2012)

well, it would be a 1 look 2 alg kinda ZBLL, slightly increasing movecount but drastically dropping the required number of algs. Whether or not it will be better than COLL/Edges we'll have to see. It is likely that the edges oriented cases will be worse than the others though. Again, have to wait and see.


----------



## yoinneroid (May 20, 2012)

kashyap7x said:


> well, it would be a 1 look 2 alg kinda ZBLL, slightly increasing movecount but drastically dropping the required number of algs. Whether or not it will be better than COLL/Edges we'll have to see. It is likely that the edges oriented cases will be worse than the others though. Again, have to wait and see.


 
this?


----------



## kashyap7x (May 21, 2012)

Yeah, that. But, from the page..


> It needs a lot more work, and is not all that reliable, but it's a start.


Its going to end up as a subset of the LL system being developed. If this system turns out superior or as good as other conventional ones the edges oriented version might be worth using too. Hopefully.


----------



## Kirjava (May 22, 2012)

Posting updates is fun :3

This is honestly going way better than I expected.

I've organised *1879/4128* cases "by alg". After the entire thing is organised in this format, it'll start getting closer to being learnable. At that point cases will start to be grouped and the actual number of cases will be reduced.

The cool part? All those cases start with Sune/FatSune/Antisune. Yeah. Almost 50% chance of the first alg being a Sune is the kind of thing I was talking about when I said 'better good case distribution'. 



Escher said:


> Although I think after finishing this (huge) task it would be cool for the community to help Kir generate and optimise a set of algs for ZBLL



I actually started doing this when I started learning ZBLL, but abandonded it when I went for OLLCP. (At that point I hadn't thought about it as much as I've thought about this though, I've found too many new ideas and improvements between then and now)

Maybe it'll be worth making a ZBLL version just to demonstrate the validity of the technique.


----------



## Noahaha (May 22, 2012)

Do you think it will ever be feasible to have a program where you can put in your fifty or so favorite algs and it will generate a learnable complete LL table using this system, sorted by the first alg?


----------



## Escher (May 22, 2012)

Kirjava said:


> Posting updates is fun :3
> 
> This is honestly going way better than I expected.
> 
> ...



That is cool O_O



Kirjava said:


> Maybe it'll be worth making a ZBLL version just to demonstrate the validity of the technique.



Definitely. Making the ZBLL subset 'learnable' using this technique would make it so, so much more viable - one could eventually replacing all 'bad' cases with more unique algs - I'm not surprised if plenty of advanced cubers would use this approach as a stepping stone. Almost like learning full OLL as just a combination of two sunes or something...

Edit: @ Noahaha, that depends on the minimum number of algorithms required, which would probably have to be brute-forced I'm guessing, a different kind of proof would have to be very elegant... It also depends on the minimum number of 'alg types' needed.
Obviously, it would be somewhat easier for ZBLL.


----------



## LarsN (May 22, 2012)

Kirjava said:


> Posting updates is fun :3


 
I'm impressed that you've gotten so far. And it's great to hear that things are turning out to be good. I'd love to be a test person if you need help of some kind or another.


----------



## Kirjava (May 22, 2012)

So looking at the organised data has given me a few ideas.

My original organisation ideas are now more of a backup incase none of the crazy things I've been thinking about work.

A flowcharting system akin to jaap's sq1 cubeshape diagram might be able to be used.

Since half the cases can be solved with some Sune variation, maybe there is a trait that they all have in common. Then maybe there is a trait that all the mirrored sune cases have in common, etc.

It might not be possible on this scale, but will def. be possible for smaller sets. Common patterns appear to crop up. It's just a huge extension of my case reduction idea.

This could get really easy. I'll release more data at some point and see if anyone can help work it out.


----------



## Godmil (May 22, 2012)

I'm really curious about what your saying about sune cases being so common (for the first move?). Is that something that was apparent from looking at the raw data, or did you say go into it wondering how many could start with a sune case?
I'm just curious if maybe you picked any group of 3 or 4 algs, if you could find they could be used for starting half of the cases.
Anyway keep up the good work, and thanks for the updates.


----------



## StachuK1992 (May 22, 2012)

http://codepad.org/xLYp8b8L


----------



## Mollerz (May 22, 2012)

I was discussing this with Kirjava last night as well, this may only really work on odd numbered cubes. OLL Parity is easy enough to spot but unless the recognition system becomes so easy that spotting PLL Parity isn't a problem, then it could potentially be problematic.


----------



## Kirjava (May 22, 2012)

This is a 3x3x3 method. I forgot that people do 3x3x3 LL on 4x4x4 too XD



Godmil said:


> I'm really curious about what your saying about sune cases being so common (for the first move?). Is that sometime that was apparent from looking at the raw data, or did you say go into it wondering how many could start with a sune case?



I just used grep to list all the cases that start with Sune. Turns out, many. 

I knew I wouldn't know exactly how I was going to organise the data until I started looking deeper at it, but I wasn't expecting this.



Godmil said:


> I'm just curious if maybe you picked any group of 3 or 4 algs, if you could find they could be used for starting half of the cases.


 
Probably, but I picked Sune because it's good. I'm hoping I can cover the other half with FRUR'U'F' etc. Should make any solution stupid fast.


----------



## blah (May 22, 2012)

Didn't read the whole thread, so my questions may have been answered: Are there "usable" necessary and/or sufficient conditions that determine if an arbitrary set of algs can solve any LL case in two steps? Naturally, the next question is what is the minimum number of algs necessary?


----------



## bobthegiraffemonkey (May 22, 2012)

Mollerz said:


> I was discussing this with Kirjava last night as well, this may only really work on odd numbered cubes. OLL Parity is easy enough to spot but unless the recognition system becomes so easy that spotting PLL Parity isn't a problem, then it could potentially be problematic.


 
I wonder if it's possible at all to treat a certain pair of opposite edges as being the same, then you would get a solved LL or pure PLL parity. Not sure how this would affect the recog system, since nobody knows what it is yet. Not that I would ever use this system for 4x4 anyway, I'll stick with going for 1-looking OLL and PLL using various tricks to make the parity cases nicer (I've 'learned' OLL already, although I've forgotten some which I need to pick up again, and I need to finish working on PLL).


----------



## Kirjava (May 24, 2012)

3577/4128

Using Sune, SexyHammer, FRURUF & DblFRURUF for first alg so far.

EDIT: 

3853/4128

Added M'UMU2M'UM, R'U'R'FRF'UR, RUR'U'M'URU'r'


----------



## Jaycee (May 24, 2012)

Kirjava said:


> & DblFRURUF


 
Hmm?


----------



## jeff081692 (May 24, 2012)

Jaycee said:


> Hmm?


 
Maybe he meant FRUR'U'F'.


----------



## Mollerz (May 24, 2012)

Jaycee said:


> Hmm?


 
F R U R' U' R U R' U' F'


----------



## Jaycee (May 24, 2012)

Mollerz said:


> F R U R' U' R U R' U' F'


 
Oh. Dbl = double. I get it.


----------



## uberCuber (May 24, 2012)

Oh boy I cannot wait to see this so I can decide how I want to apply it to 4x4.


----------



## Akash Rupela (May 24, 2012)

I m not really sure what i m saying, but rather than having most cases start with sune, wont it be better to group them such as the starting alg is same depending on certain common characteristics(i know its something tough and saying is easy but still)?

Also, Great job, i hope this is in learnable or even semi-learnable form(something more learnable than the previous one), cuz i have holidays till mid july, so would be good if i can get this soon


----------



## Cubenovice (May 24, 2012)

Akash Rupela said:


> I m not really sure what i m saying, but rather than having most cases start with sune, wont it be better to group them such as the starting alg is same depending on certain common characteristics(i know its something tough and saying is easy but still)?



Let's wait a little bit and see the final output and proposed recognition.
Once the full set is available* you're free to reorganise in any way you like.

Thom,
the times of your posts make me wonder: how much sleep do you get nowadays?

Anyway, keep up the good work but make sure you don't crash...
We can wait (but you probably cannot )

*
Thom, I propose you that you put a paypal "donate" button onto the page you're going to publish this


----------



## LarsN (May 24, 2012)

Kirjava said:


> *3853/4128*
> Added M'UMU2M'UM, R'U'R'FRF'UR, RUR'U'M'URU'r'



Forget about the rest. Lets just make some 1LLL algs for those few cases


----------



## Kirjava (May 24, 2012)

Akash Rupela said:


> I m not really sure what i m saying, but rather than having most cases start with sune, wont it be better to group them such as the starting alg is same depending on certain common characteristics(i know its something tough and saying is easy but still)?



This is the idea I proposed most recently. I'm going to attempt to apply it to what I have once it's already organised. If that doesn't work, I'll finish documenting it in this style and look to do it the other way from scratch, although that will take a lot longer than this way did. (Maybe, since I thought it'd take months to get to the stage I am at now.)



Cubenovice said:


> Let's wait a little bit and see the final output and proposed recognition.
> Once the full set is available* you're free to reorganise in any way you like.



People are already free to reorganise it however they like, since the full table is available. 

Maybe I'll put my organised version on the wiki once it's finished so people can constantly improve it.



Cubenovice said:


> the times of your posts make me wonder: how much sleep do you get nowadays?



5 or so hours a night during the week.



Cubenovice said:


> Anyway, keep up the good work but make sure you don't crash...
> We can wait (but you probably cannot )



Thanks! It's actually quite enjoyable to do this, so I don't mind all that much at the moment. The fact that I might have something tangible soon is great motivation.



Cubenovice said:


> Thom, I propose you that you put a paypal "donate" button onto the page you're going to publish this



I appreciate the sentiment, but I do it for the love <3



LarsN said:


> Forget about the rest. Lets just make some 1LLL algs for those few cases


 
275 is way too many, I'd prefer to only have to do 10 or so.

One thing that's bugging me is that the more I document, the fewer cases each alg covers. I think once I hit about 100 left I'll organise them by hand.


----------



## Cubenovice (May 24, 2012)

Kirjava said:


> One thing that's bugging me is that the more I document, the fewer cases each alg covers. I think once I hit about 100 left I'll organise them by hand.



Or perhaps you throw in a couple more nice algs and run the solver again, just on those remaining cases.
Maybe now is already the right moment for such an excersize?


----------



## bobthegiraffemonkey (May 24, 2012)

Even though I will likely only use a small subset of these I would probably send a small token of appreciation via that donate button if you decide to have one, mostly out of kudos for pulling this craziness off (when/if it gets organised into a good format), and I'm sure quite a few others would too. Just sayin' .


----------



## asportking (May 24, 2012)

Cubenovice said:


> Or perhaps you throw in a couple more nice algs and run the solver again, just on those remaining cases.
> Maybe now is already the right moment for such an excersize?


Which ones is he using now? I agree, using a few more would probably help.

This method sounds like it'll be really fast and useful. One thing I don't quite get is this:



Kirjava said:


> Each case only needs one solution, and the number of cases you need to memorise will end up being quite a bit smaller than the number of actual LL cases.



I can understand why you'd need to memorize significantly less algs than there are cases, but wouldn't you still have to memorize which two algs you use for every case?


----------



## Kirjava (May 24, 2012)

asportking said:


> I can understand why you'd need to memorize significantly less algs than there are cases, but wouldn't you still have to memorize which two algs you use for every case?


 
No. You only need to learn the first alg for each case, and my case reduction idea combines recognition from multiple cases into one.


----------



## Petro Leum (May 24, 2012)

so would be sune/antisune and niklas /antiniklas (lol) as first alg be an option for methods like ZZ were teh edges are already oriented?


----------



## AbstractAlg (May 24, 2012)

This sounds amazing. Can't wait for it. *_*
Idea is amazing, good luck!!


----------



## Kirjava (May 25, 2012)

Petro Leum said:


> so would be sune/antisune and niklas /antiniklas (lol) as first alg be an option for methods like ZZ were teh edges are already oriented?


 
I might make a ZBLL version, but I don't really want to because this idea doesn't work as well if you're doing EOLS aswell.


----------



## mullemeckmannen (May 31, 2012)

how´s it going Kirjava?


----------



## Dacuba (May 31, 2012)

mullemeckmannen said:


> how´s it going Kirjava?


 
Be patient. Good stuff needs time.
He will bump the thread by himself when he is ready for more updates.


----------



## Kirjava (Jun 8, 2012)

Wow that was a lot of work. Updates!

Sorry this took so long, the more cases you do, the harder it is to do more at once, since less cases are available to be covered by a single alg.

So I've organised all 4128 cases by algorithm. At the moment I've just got it organised loosely in a bunch of files, I'll convert this to a sexy HTML format for people to oogle at sometime soon.

That'll end up being the final product eventually. However, it still won't be very friendly initially, but will be somewhat learnable! A lot of work will still need to be done, but all the initial grind it out of the way - all that's rest is fun discovery 

I need to do case reduction, find patterns and discover other shortcuts. Please help once I've posted the neat version if you have any idea what I'm talking about 

I've found a few patterns and little quirks already, but it's kind of hard to spot with how the data is now. Once it looks pretty it should be a lot easier to improve :3 Just need to keep throwing man hours at the damn thing until it's playing nice >


----------



## sa11297 (Jun 8, 2012)

Kirjava said:


> Wow that was a lot of work. Updates!
> 
> Sorry this took so long, the more cases you do, the harder it is to do more at once, since less cases are available to be covered by a single alg.
> 
> ...


awesome, your work is much appreciated


----------



## jeff081692 (Jun 12, 2012)

So I started my feeble attempt at learning this and I wonder is the number of cases really 4128? For example I counted at least 26 cases that were actually PLL cases. Also When practicing recognition I noticed that image 464 and 553 are the same case just a different AUF which leads me to believe that more cases could be over counted. 
example: case 464 solution is U Inv(Sune) Inv(Sune) and case 553 solution is U' Inv(Sune) Inv(Sune).


----------



## Kirjava (Jun 22, 2012)

The site's starting to come together.







It's taking forever because there are thousands of cases. I've been writing little scripts and stuff to speed things up, but it's still a lot of grinding.


----------



## Christopher Mowla (Jun 22, 2012)

Thom,

This is the first time I looked at this thread (sorry!). I have read all of it, and I have a question.

Maybe I missed something, but, by looking at the raw data table, you seem to have dozens of algorithms for each case. How are you (or anyone else) supposed to organize theses cases by algorithms if there is more than one alg listed for each case? I might be interested in helping, but I don't know where to start because of this.

Guess: Is it to choose the algorithm for each case so that we have the minimum number of subsets? If so, how are you separating subsets? I've read that you are gearing to have algorithms start with sune, antisune, etc. Is that your approach? If so, what is the "second best" starts to continue with after that? And after that?...

If I didn't guess right that time, is it based on speed (I am aware that you have chosen fast algs to generate all cases, but I am referring to when they are combined)? If so, how is anyone ever going to agree on this (since there are so many alg combinations for each case)?



Noahaha said:


> A lot of LL situations are just a 3-cycle of corners and a 3-cycle of edges. It would only be like 20 algs to give a lot of 2-alg 1LLLs.
> 
> EDIT: 12 edge cycles and 12 corner cycles, and not too bad algs either.


I don't know what the "actual" number is, but from the raw number of cases (with mathematics) for 3-cycles of edges and corners, if I did my calculations right, is 22.2% of the raw number of LL cases:

\( \frac{\left( 8\times 3^{3} \right)\left( 8\times 2^{3} \right)}{\frac{1}{2}\left( 4! \right)\left[ 2^{3} \right]\left( 4! \right)\left[ 3^{3} \right]}=\frac{2}{9}. \) But this is all irrelevant to this thread anyway.


----------



## LarsN (Jun 22, 2012)

Kirjava said:


> The site's starting to come together.



Sounds great. Are there any news on a potential recognition method?


----------



## Kirjava (Jun 22, 2012)

cmowla said:


> Maybe I missed something, but, by looking at the raw data table, you seem to have dozens of algorithms for each case. How are you (or anyone else) supposed to organize theses cases by algorithms if there is more than one alg listed for each case? I might be interested in helping, but I don't know where to start because of this.



What I've been doing is taking the list of all cases, and removing the cases that start with a specific algorithm. So first, I took all cases that start with Sune and seperated them into their own group. The rest of the combinations are ignored. 



LarsN said:


> Sounds great. Are there any news on a potential recognition method?



Hm.

Not yet. I was going to look to find patterns after the data is organised in this format. However, I was talking to someone on IRC last night and after it's done this way will look into doing a flowcharting based system instead. I have a lot of ideas for this, and I can imagine by the time this is finished the data will be explorable in a plethora of different ways.


----------



## Zarxrax (Jun 28, 2012)

What about applying this system to the 2x2 cube?
With only 40 cases for CLL, it could serve as a nice test of the idea before completing the whole 3x3 version. And I'm curious how nice the algs would be.


----------



## Kirjava (Jun 28, 2012)

I've been able to do 'this system' on 2x2x2 for like 6 years. It's just niklas/sune/fruruf combinations.


----------



## nickvu2 (Jun 28, 2012)

Kirjava said:


> I've been able to do 'this system' on 2x2x2 for like 6 years. It's just niklas/sune/fruruf combinations.



Do you have documentation for that!?


----------



## Kirjava (Jun 28, 2012)

It doesn't really need to be documented. Most of the time you do CP then CO or CO then CP and it'll get it in two algs. You just have to learn the combos.


----------



## irontwig (Jul 24, 2012)

Still working on this?


----------



## Cubenovice (Jul 24, 2012)

Kir's brain is too busy 

I prefer the "guide" to "brute forcing" optimal 2x2x2 and 2x2x3 anyway.


----------



## Kirjava (Jul 24, 2012)

irontwig said:


> Still working on this?



Not as much as I was doing, as Nats is coming up and I've been doing a lot of practise.

However, I should get in some sort of releasable state soon.

Sorry for the delays. Life, etc. You're free to help out if you want to.


----------



## Kirjava (Jul 26, 2012)

heh. thanks for the nudge.

sunk another hour or two into this today and have about 48% of cases complete.

by complete, I mean listed by alg. once this is fully done, I'll release it.

that'll be version 1! after that, work will be done on moving cases around, finding patterns, and removing isomorphic cases.

grindgrindgrindgrind


----------



## StachuK1992 (Aug 28, 2012)

Any updates?


----------



## Kirjava (Aug 28, 2012)

I post updates when I have them


----------



## dregerdoes (Sep 21, 2012)

When this is all together, it may turn out to be one of the most interesting ways to go about finishing it. The cases that could occur would be intriguing to learn and you would definitely have a new way that others wouldn't. If nothing else it is a way about finishing it with originality.


----------



## Kirjava (Sep 26, 2012)

*Update in this post*

I'm getting tired of people assuming I'm not working on this and complaining that it is not finished, so I'm releasing my progress so far. *This is a lot of work, stop complaining that it's taking so long. I have other things to do.* I was going to hold off until I'd got more of it done, but cba to put up with people anymore.

What's done; Every case is listed under its initial alg. This was the bulk of the work and brings the system to the basic format for the 'learnable verson'.

What needs to be done; Further organisation of cases to reduce the number of sets, duplicate removal, smarter case grouping, case number and recognition reduction.

Def. the biggest project I've worked on so far - the grind combined with the nagging greatly increases apathy 

TL;DR - still a work in progress, link is below

http://snk.digibase.ca/ll/


----------



## miotatsu (Sep 26, 2012)

this is crazy, great job on all this!


----------



## Brest (Sep 26, 2012)

Wow that's amazing. And daunting. <3


----------



## MaeLSTRoM (Sep 26, 2012)

Wow...
Just wow...
Could you possibly put some images to show the second stage cases and the respective algs, so that it's easier to see if you've got the right angle for the first alg.


----------



## Kirjava (Sep 26, 2012)

MaeLSTRoM said:


> Wow...
> Just wow...
> Could you possibly put some images to show the second stage cases and the respective algs, so that it's easier to see if you've got the right angle for the first alg.



A mouseover would be cool but would be too much effort at this point. 

Why would you have trouble getting the right angle?


----------



## aznanimedude (Sep 26, 2012)

now that i actually see this, this is quite impressive yo~


----------



## Kirjava (Sep 27, 2012)

While (if?) anyone is learning this and notices any improvements or things that can be removed or moved around, your input would be appreciated.

I was thinking of putting this thing in GitHub so we could collaborate? Progress would be a lot faster, but would anyone actually do this?

More ideas; ability to search for a specific case (I planned ahead and left info in the files in case I wanted to do this), AUF removal


----------



## StachuK1992 (Sep 27, 2012)

I think the mouseover is a great idea.

Since you divide these into sections by the first alg performed, I was thinking maybe:
-throw each picture under "sune" as class="sune"
-somehow use php to write javascript functions that deal with just adding "[sune]" to the end of the alg?

Not sure if that makes sense, but mouseover would be really nice. Throwing this on github would be nice for this, too.


----------



## MovingOnUp (Sep 27, 2012)

From what I understand, this looks freaking awesome, great work. Going to wait until "learn-able version" is organised though haha,


----------



## Kirjava (Sep 27, 2012)

StachuK1992 said:


> I think the mouseover is a great idea.
> 
> Since you divide these into sections by the first alg performed, I was thinking maybe:
> -throw each picture under "sune" as class="sune"
> ...



The images are static and do not use visualcube. However, I worked out a way I can do this.

Easy image tag is assigned an id that corresponds to the orientation and permutation of the pieces. I can write code that applies the alg and works out the new position.



MovingOnUp said:


> Going to wait until "learn-able version" is organised though haha,



This is the "learnable version". All there is to do from here is just improve it.


----------



## bobthegiraffemonkey (Sep 27, 2012)

Kirjava said:


> This is the "learnable version". All there is to do from here is just improve it.



Hmm, I'm not sure I would personally call it "learnable" quite yet since as it stands people would have to learn each case individually one section at a time (unless I'm missing something you've done already?), although it's certainly came a long way already. Do you have any suggested ideas about recognition?


----------



## Kirjava (Sep 27, 2012)

bobthegiraffemonkey said:


> Hmm, I'm not sure I would personally call it "learnable" quite yet since as it stands people would have to learn each case individually one section at a time (unless I'm missing something you've done already?), although it's certainly came a long way already. Do you have any suggested ideas about recognition?



Actually, I'd call it learnable - just not friendly yet. Learning cases is much easier than learning algs.

I don't think 1LLL recognition is very hard, it's the recall people have trouble with. Recognition will be improved and easier for some of the cases, but the majority will need 1LLL.

I can't seem someone learning this system without putting in some effort themselves to design methods of recognition and learning to aid them, so part of this will be left open to allow people to implement the system in a way they prefer.


----------



## Speedmaster (Sep 27, 2012)

I really want to learn this kind of LL, but i can't imagine recognise the cases and learning all the combinations of the cases..., how many cases are there? and what's the best way to recognise them?? corners first? and then edges? and if it takes a long time (1s) it will be fast too, because you don't have to recognise 2 things, and the algrhitms, are fast too


----------



## EMI (Sep 27, 2012)

Kirjava said:


> Actually, I'd call it learnable - just not friendly yet. Learning cases is much easier than learning algs.
> 
> I don't think 1LLL recognition is very hard, it's the recall people have trouble with. Recognition will be improved and easier for some of the cases, but the majority will need 1LLL.
> 
> I can't seem someone learning this system without putting in some effort themselves to design methods of recognition and learning to aid them, so part of this will be left open to allow people to implement the system in a way they prefer.



hm, I think 1LLL is quite hard to recognize (recalling might be even harder). OLL and PLL are very easy to recognize and recall. I doubt this method will be as good as normal OLL/PLL.


----------



## MovingOnUp (Sep 27, 2012)

I don't understand how your website is organised. You click on the OLL alg type i.e. "Sune" and then what are you supposed to do ? For every one of those cases you do Sune and then from there how does it work? I must be missing something


----------



## aznanimedude (Sep 27, 2012)

i think the idea is that the last layer is solvable using a very small set of algorithms.

and the set of algorithms are ones that are really fast to execute.

so for the sune cases, you first do Sune, then you do another algorithm from the set up there.

recognition is going to be pretty beastly but man, if anyone got this down, i mildly envy the last layer they will have :|


----------



## Muesli (Sep 28, 2012)

Thom, you are a beast. This is incredible stuff.


----------



## Kirjava (Sep 28, 2012)

Speedmaster said:


> I really want to learn this kind of LL, but i can't imagine recognise the cases and learning all the combinations of the cases..., how many cases are there?



No idea yet. There are about 4000 at the moment but this number should be reduced by a lot eventually.

I learned a system 1/12th the size of this in about two months - and that was without any kind of organisation.



Speedmaster said:


> and what's the best way to recognise them?? corners first? and then edges? and if it takes a long time (1s) it will be fast too, because you don't have to recognise 2 things, and the algrhitms, are fast too



Dunno, however you like really. I don't personally find 1LLL hard.



EMI said:


> I doubt this method will be as good as normal OLL/PLL.



There are many benefits to this system over OLL/PLL, but if you have trouble recognising fast enough or learning all the cases OLL/PLL might be a better system for you.



MovingOnUp said:


> You click on the OLL alg type



lol

try reading the rest of the thread


----------



## irontwig (Sep 28, 2012)

If I would be crazy enough to learn this I'd probably want it organized according to case rather than alg. And maybe for learning this kind of system you might want to use something like Anki or a similair flashcard program, since there's no real need to drill the algs into muscle memory, since you probably already know how to do e.g. a Sune, and also you would get the cases you've trouble with more often than the rest rather than the random distribution when just doing solves.


----------



## Kirjava (Sep 28, 2012)

irontwig said:


> If I would be crazy enough to learn this I'd probably want it organized according to case rather than alg.



It already is. Click on full table.


----------



## MalusDB (Sep 28, 2012)

Anybody else having problems loading the full page? Or is it just me and my Uni internet sucking hard..? Kir thats a serious amount of leg work you put in on this. Fair play.


----------



## MaeLSTRoM (Sep 28, 2012)

MalusDB said:


> Anybody else having problems loading the full page? Or is it just me and my Uni internet sucking hard..? Kir thats a serious amount of leg work you put in on this. Fair play.



Trying to load the full table is some serious load on a connection. Earlier in the thread there is a zip of the full table, if you download that and open it locally it should be OK.


----------



## Speedmaster (Sep 28, 2012)

I don't really understand how this full table works..., if i look at the case above, there are just 100 different combinations of algrhitms under it, what do they stand for?
Do you think, this LL system can be used for speedsolves? or should i just learn on set of the algrhitms for speedsolves like Feliks learned some ZBlls for the U cases (I think)?


----------



## MaeLSTRoM (Sep 28, 2012)

Speedmaster said:


> I don't really understand how this full table works..., if i look at the case above, there are just 100 different combinations of algrhitms under it, what do they stand for?
> Do you think, this LL system can be used for speedsolves? or should i just learn on set of the algrhitms for speedsolves like Feliks learned some ZBlls for the U cases (I think)?



Basically the full table is the list of possible ways to solve that case using the 2 shorter algs. Certain combinations have been seected and then sorted into the other pages, but not all combinations are good. If you're using the full table then find a combination you like.
As for learning other sets, you can learn whatever you like. doing this will be a /lot/ of effort and time.


----------



## Speedmaster (Sep 28, 2012)

So I only have to learn *one* algrhitm of the hundred ones which are under the picture??


----------



## AHornbaker (Oct 9, 2012)

Sounds awesome, but im not sure i completely understand it. Full OLL/PLL suggests 1197 cases (57*21) for 1LLL. The most efficient way to break these up into two groups would be roughly 34 in each as 34*34=1156 which would be a total of 68 algs, a lot more than 46. Also, i looked at the tables and didnt understand most of it. Would love to learn this, can someone explain it to me in simpler terms?


----------



## Noahaha (Oct 9, 2012)

AHornbaker said:


> Sounds awesome, but im not sure i completely understand it. Full OLL/PLL suggests 1197 cases (57*21) for 1LLL. The most efficient way to break these up into two groups would be roughly 34 in each as 34*34=1156 which would be a total of 68 algs, a lot more than 46. Also, i looked at the tables and didnt understand most of it. Would love to learn this, can someone explain it to me in simpler terms?



There are 1156 possible OLL/PLL combinations, but there are actually well over 10,000 possible LL positions. What Kirjava has done is taken every LL position and given one of 46 algs to execute that will reach a position solvable by one of those same 46 algs. 

What you didn't take into account is that 46 algs can actually reach 46*4 = 184 possible positions due to being performed at different angles. 

So 184*184>#of LL positions.


----------



## AHornbaker (Oct 10, 2012)

By that logic, you could use at the least 34 algs, so 46 sounds achievable


----------



## Kirjava (Oct 17, 2012)

Ok. Since I'm currently focusing on getting faster at 3x3x3 at the moment I don't intend to learn this system myself until some point in the future.

However, I would still like to keep up development of it - which I will cease to do for now if I'm the only person planning to learn this.

I don't think this can truly be 'completed' unless it's done in conjunction with learning it - because of this, I'd like to find someone intending to learn this to work with me at developing it. When I did OLLCP, I basically had to go through each subset and produce some information that is currently unpublished (and only exists in my head) to ease learning by a huge factor. Stuff like this can't be discovered without basically learning the entire thing. Also it'd give me huge motivation to know that it was actually being used :U.

Basically, the base material is there for someone to learn this if they put their own effort in. I'm willing to put the effort in if someone is willing to learn it. srs offers only plz.


----------



## Ickathu (Oct 17, 2012)

How many algs are we talking about? (too lazy to check)
I don't do 3x3 that often, but I'll learn the algs (or at least try to as long as it's not an obnoxious amount) and practice it. How would you learn the algs? Just pick a set and learn all of them, then continue? How is it going to be broken down? By orientation, permutation, or both?


----------



## Kirjava (Oct 17, 2012)

Ickathu said:


> How many algs are we talking about? (too lazy to check)
> I don't do 3x3 that often, but I'll learn the algs (or at least try to as long as it's not an obnoxious amount) and practice it. How would you learn the algs? Just pick a set and learn all of them, then continue? How is it going to be broken down? By orientation, permutation, or both?



You are completely the opposite of what I need.  You should probably understand what I'm asking before you offer to take part.


----------



## Godmil (Oct 17, 2012)

Ickathu said:


> How many algs are we talking about? (too lazy to check)
> I don't do 3x3 that often, but I'll learn the algs (or at least try to as long as it's not an obnoxious amount) and practice it. How would you learn the algs? Just pick a set and learn all of them, then continue? How is it going to be broken down? By orientation, permutation, or both?



nonono, there are only a handful of algs. What is needed is learning 1000+ cases of when to use which two (and I pressume which AUF to do in between them).


----------



## Kirjava (Oct 17, 2012)

You don't need to learn which AUF and second alg unless you're planning to learn it as a 1 look system - you only need to learn the first alg.


----------



## jeff081692 (Oct 17, 2012)

I can put 2 hours a day into learning this. Do you really think it is better to learn by alg instead of take like a ZBLL case and learn the 40 or something algs then practice the recognition for it then move on to another case? The second option is how I always imagined I would learn it.

Edit: you just answered that. I was planning on learning it as a 1 look but I understand what you mean now.


----------



## JonnyWhoopes (Oct 17, 2012)

Kirjava said:


> You don't need to learn which AUF and second alg unless you're planning to learn it as a 1 look system - you only need to learn the first alg.



This just made me understand how it's even possible to learn this system. I was thinking this was a 1 look system. Now this makes me wish I had the time to dedicate to this...


----------



## Kirjava (Oct 17, 2012)

jeff081692 said:


> I can put 2 hours a day into learning this. Do you really think it is better to learn by alg instead of take like a ZBLL case and learn the 40 or something algs then practice the recognition for it then move on to another case? The second option is how I always imagined I would learn it.



If you'd like to learn it like that then no more work needs to be done - the full table has the data in this format ready to be learnt.

However! I just had a batshit brainwave. A combination of the two would be ****ing delicious.

So you will have the LL split up into CLL cases, and WITHIN that subset, the cases are listed by alg. This could make learning it actually achievable - as it's practisable.

I think this might just be the format that works for the idea. Why didn't I realise this before doing the entire thing ;-;.

So I guess I'll do an LL subset and release it, see how people get on.

God damn this is so much work :U


----------



## Ickathu (Oct 17, 2012)

Kirjava said:


> You are completely the opposite of what I need.  You should probably understand what I'm asking before you offer to take part.



 I've been following this thread since the beginning, I'm just a bit confused how it's broken down. I understand what it is: 1 alg to give an easy 1 alg finish. I've been doing this some recently when I get a CLL skip and edges aren't permuted. I'll use a TuRBo alg to do EO and set up into an easy EPLL, or even if corners aren't solved I'll solve into an A-perm, and stuff like that. But you're probably right; I'd probably be a bad person to learn this first haha. Maybe once it's a bit more refined and some other people have done it I'll try and throw in my input


----------



## jeff081692 (Oct 17, 2012)

Kirjava said:


> So you will have the LL split up into CLL cases, and WITHIN that subset, the cases are listed by alg. This could make learning it actually achievable - as it's practisable.



Yea that sounds really cool. Since I was learning ZB like cases first I was using this page
http://www.speedsolving.com/wiki/in...?mode=view&view=default&puzzle=3&group=ZBLL-H
since the cases are organized and I was making a text document with corresponding numbers and the alg from your table.
I didn't get very far though yet.


----------



## Kirjava (Oct 17, 2012)

Yeah, I'm just gonna go through the damn thing and do it one by one, so I can reduce cases myself.

I'll do the 'A' CLL set first (the one with corners oriented). Then maybe someone can use WV to practise it to check how feasable learning the subsets is. 

Once it's shown to actually work, I'll document the other CLLs.

This could be organised in other ways, too - OLL, ELL. However, reducing the number of cases from the 'true' number relies on the way the cases are organised. I think CLL is the best route to take to minimise number of cases (OLL would give almost no reductions).


----------



## A Leman (Oct 17, 2012)

Sorry Thom, this seems a bit too much for me at the moment. About 4000 cases would be overwhelming for me as I am now. I looked into it; This would be like learning 8000 digits of pi for me and I have trouble seeing how much faster it would be than the more standard large systems like OLLCP or ZB


----------



## MaeLSTRoM (Oct 17, 2012)

I am considering learning this. Seriously.
Also, Like I said before I don't mind helping with the organising of the cases. Might learn it a bit slowly to start with though, just because 3x3 is much of a focus for me.
Also, this could be pretty boss for K4, just like reduce to L2E in 1 look


----------



## Zarxrax (Oct 17, 2012)

This sounds like a lot of work and time to invest, but I haven't seen anything yet to indicate that a logical and efficient recognition system can be built from this. Assuming that the entire purpose of all of this work is to discover that recognition system, isn't it also possible that no good recognition method exists, and this is all just a bunch of hard work from which nothing will ever materialize?
If it turns out that people may have to learn to recognize hundreds or thousands of cases to make this method viable, then will it even still have any theoretical benefit to learning this?


----------



## Kirjava (Oct 17, 2012)

Since when was recognition a problem? You recog the 1LLL case like any other - make up your own system, it's not hard.


----------



## Zarxrax (Oct 17, 2012)

So you basically just have to memorize like 1000+ cases?
My understanding from the beginning was that as it could be a 2-look system, there was going to be some way to massively cut down the amount of cases needed to be recognized during the first look?
How again is this supposed to be any better than other massive last layer systems that had fewer cases but never caught on?


----------



## Kirjava (Oct 17, 2012)

Zarxrax said:


> So you basically just have to memorize like 1000+ cases?
> My understanding from the beginning was that as it could be a 2-look system, there was going to be some way to massively cut down the amount of cases needed to be recognized during the first look?
> How again is this supposed to be any better than other massive last layer systems that had fewer cases but never caught on?



None of this is anything to do with the system you use to recognise cases. 

You seem to have trouble understanding this system.

It's ok though, I don't need your approval


----------



## Zarxrax (Oct 17, 2012)

I'm just trying to understand exactly how this works and how it will be beneficial. I think I'm probably not the only one who doesn't really get it.


----------



## uberCuber (Oct 17, 2012)

Zarxrax said:


> So you basically just have to memorize like 1000+ cases?



Just memorizing cases is much easier than memorizing a new alg for every case. 1000+ seems like a ridiculous number, but when every alg is easy and already familiar, (I'm assuming, I didn't look at every alg in the Misc section of the site), I don't see learning this as is as inherently difficult at all. Why? If I'm already really familiar with all algs involved, learning these cases is something I could easily do without a cube, which would tremendously speed up the process. If I wasn't busy memorizing parityOLL and stuff for 4x4, I'd start learning some of this myself right now.


----------



## Kirjava (Oct 17, 2012)

I think I'd hold off on learning just now until I've started the next revision, am hoping it'll be quite friendly to learn this time.


----------



## Speedmaster (Oct 17, 2012)

Could anybody explain me this system, as easy as possible? All I know is, that there are lots of cases and you look at one and use two fast algs to solve one case and you don't have to learn the algs, but the combinations of them and the recognition. But there are so many cases, how is it possible to recognise all of them fast??!


----------



## Zarxrax (Oct 17, 2012)

uberCuber said:


> Just memorizing cases is much easier than memorizing a new alg for every case. 1000+ seems like a ridiculous number, but when every alg is easy and already familiar, (I'm assuming, I didn't look at every alg in the Misc section of the site), I don't see learning this as is as inherently difficult at all. Why? If I'm already really familiar with all algs involved, learning these cases is something I could easily do without a cube, which would tremendously speed up the process. If I wasn't busy memorizing parityOLL and stuff for 4x4, I'd start learning some of this myself right now.



Really? I've personally always found it to be MUCH more difficult to memorize the cases than it is to remember algorithms. But everyone is different I guess.


----------



## bobthegiraffemonkey (Oct 17, 2012)

I'd like to eventually see this sorted by CLL. I had an idea before of learning this for bad COLL cases (I had ideas of EO hacks for big cubes, which kinda failed when I tried them, but I've not completely given up on it yet), but you could do this with bad CLL cases instead. Good CLL: CLL->ELL, bad CLL: this. I'm busy with other stuff so I don't see myself putting in any hard work on this unfortunately, if I had more free time I would seriously consider it.


----------



## jeff081692 (Oct 17, 2012)

Speedmaster said:


> Could anybody explain me this system, as easy as possible? All I know is, that there are lots of cases and you look at one and use two fast algs to solve one case and you don't have to learn the algs, but the combinations of them and the recognition. But there are so many cases, how is it possible to recognise all of them fast??!



Say for instance you decided to learn 1 look last layer. You would need to be able to recognize 1000+ cases and each case has a unique algorithm to learn so that is 1000+ algorithms. What this method does is makes it so you don't have to learn so many algorithms, instead all you would need to know to 1 look a case is to know which 2 algorithms to apply out of the small pool of fast algorithms. It is easier to see a case and recognize it as the combination of two known cases than to recall one alg out of 1000+. 
But even this could be a bit extreme starting out. So to use this as a two look system all you would need to know when you arrive at a case is which is the first alg. Once you do the first alg, the cube will be in a familiar state (assuming you know the other algs in the pool) and you can finish the cube with the second alg. 
That's the best explanation of the system I can come up with. Recognition is the only thing that needs to be learnt. It is definitely possible to recognize the difference between cases. The only way to get faster at that is practice. As people learn this system they will be able to give back information to the community that makes recognition easier.


----------



## mDiPalma (Oct 17, 2012)

If all edges are oriented beforehand, exactly how many of these cases would then be required? 1/4 of the total?


----------



## vd (Oct 17, 2012)

mDiPalma said:


> If all edges are oriented beforehand, exactly how many of these cases would then be required? 1/4 of the total?



1/8, if I am right?


----------



## Speedmaster (Oct 17, 2012)

jeff081692 said:


> Say for instance you decided to learn 1 look last layer. You would need to be able to recognize 1000+ cases and each case has a unique algorithm to learn so that is 1000+ algorithms. What this method does is makes it so you don't have to learn so many algorithms, instead all you would need to know to 1 look a case is to know which 2 algorithms to apply out of the small pool of fast algorithms. It is easier to see a case and recognize it as the combination of two known cases than to recall one alg out of 1000+.
> But even this could be a bit extreme starting out. So to use this as a two look system all you would need to know when you arrive at a case is which is the first alg. Once you do the first alg, the cube will be in a familiar state (assuming you know the other algs in the pool) and you can finish the cube with the second alg.
> That's the best explanation of the system I can come up with. Recognition is the only thing that needs to be learnt. It is definitely possible to recognize the difference between cases. The only way to get faster at that is practice. As people learn this system they will be able to give back information to the community that makes recognition easier.


Thank you 
Now I understand it ;D


----------



## AHornbaker (Nov 30, 2012)

I've been following this thread for a while and have looked at the tables, but I'm not sure I understand it. What are the algs underneath each graphic in the full table/which algs do you choose from for the pool of algs?


----------



## JasonK (Nov 30, 2012)

AHornbaker said:


> I've been following this thread for a while and have looked at the tables, but I'm not sure I understand it. What are the algs underneath each graphic in the full table/which algs do you choose from for the pool of algs?



Each of the "algs" underneath the case is a different way of solving that case. Everything between two > symbols is one "alg".

eg. The first case (H-Perm) can be solved with DoubleSune U' DoubleSune, or with TripleSune F'RD2R'FU2F'RD2R'FU2, or any of the other solutions in the list.


----------



## AHornbaker (Nov 30, 2012)

So I'm assuming Kirjava is working on making a small pool of algs that can be used for every case? Without that the site is just a list of algs for every permutation of the last layer.


----------



## Kirjava (Nov 30, 2012)

AHornbaker said:


> So I'm assuming Kirjava is working on making a small pool of algs that can be used for every case? Without that the site is just a list of algs for every permutation of the last layer.



I've already done this. There's an organised version of the system other than the full table.

Next step is to seperate into learnable subsets. At some point...


----------



## elrog (Mar 17, 2013)

I know that you already wanted everyone to stop assuming you were not working on this, but people can't help asking because it is such a great idea. If used with a method that preorients edges such as ZZ or partial edge control used with each slot resulting in edges oriented by the time you reach the last slot, then you could use partial corner control with the last slot and only deal with cases with edges oriented and atleast one corner oriented correctly. This would further reduce cases and alg numbers. What I am wanting to say though, is that you could make cases like these that would be subsets of the whole thing first so that people can use these while you are generating the rest.


----------



## redbeat0222 (Mar 17, 2013)

Pretty gord. I really need the better Last Layer.


----------



## Kirjava (Mar 17, 2013)

elrog said:


> What I am wanting to say though, is that you could make cases like these that would be subsets of the whole thing first so that people can use these while you are generating the rest.



Yeah, I was planning on doing the "A" CLL cases subset first as a trial and seeing how it worked out after people had learned it. Then I could get the motivation to move onto other stuff.

It's just work that'll I'll do at some point.


----------



## AHornbaker (Mar 26, 2013)

Here's a thought:
For recognition of all LL cases, you could use a modified 2 side PLL recognition. Not sure how well you would be able to recognize a PLL case (with any of 57 given orientations), but if someone went through all the cases and figured out how doable it is, it could be a workable solution. Someone with programming skills could map out all the LL cases, analyze each from the four 2-side recognition cases for each (showing U, F, and R faces), and see how many distinguishable LL cases can be recognized this way.


----------



## elrog (Mar 26, 2013)

The permutation of the top layer is very easy to recognize so long as corners are oriented. Without corners being oriented, I think you'd need to see alteast 3 sides (not counting the top of course). Mapping them out would also be an enormous task. You do realise that you'd have to check every possible case with every possible AUF? (number of cases times 4)


----------



## rj (Mar 26, 2013)

Once it becomes popular, then I will learn it--_if_ it is less algorithms than fridrich.


----------



## Speedmaster (Mar 26, 2013)

But that will never happen, just look at the number of algs now..


----------



## aznanimedude (Mar 26, 2013)

rj said:


> Once it becomes popular, then I will learn it--_if_ it is less algorithms than fridrich.



well you're in luck
it IS indeed less algorithms than friedrich, assuming you mean OLL+PLL.

and why not just be that person that makes it popular?

don't confuse # algorithms with # cases, #cases is mildly large, but the number of algorithms necessary to know is not


----------



## mark49152 (Mar 26, 2013)

elrog said:


> The permutation of the top layer is very easy to recognize so long as corners are oriented. Without corners being oriented, I think you'd need to see alteast 3 sides (not counting the top of course). Mapping them out would also be an enormous task. You do realise that you'd have to check every possible case with every possible AUF? (number of cases times 4)


Two sides and top should be enough, because given all the information visible on those for each case, there's only one possible state for the information not visible.


----------



## AHornbaker (Mar 29, 2013)

mark49152 said:


> Two sides and top should be enough, because given all the information visible on those for each case, there's only one possible state for the information not visible.



That's my thinking. It would be a little harder to identify misoriented pieces, especially corners, but with a good understanding of the PLL cases and color scheme this can be overcome. After that it would be a question of how well the recognition system meshes with the way the cases are split up.

EDIT: I've been playing around with this and haven't come across any cases that didn't work so far


----------



## cubacca1972 (Mar 29, 2013)

By extension (by reduction?), if you were to apply this line of LL solving to a 2 look CxLL, can the total number of required algorithms for CxLL be reduced to less than 9 (7 orientation cases including mirrors, 2 permutation cases)? I only ask this for scientific (I'm lazy and want to see if a 2 look CMLL can be reduced even further down from the 2 A cases and the best of B through H cases) purposes.


----------



## elrog (Apr 13, 2013)

Doing a 1LLL would be just as easy/hard with any other 2-alg system. You would learn the cases and know which 2 algs to use for that particular case. Other 2-alg systems may require more algs, but they're not at all unlearnable because of alg count. Other 2-alg systems wouldn't have to have the need of learning every case because they can be done in 2-looks possibly providing a way to eventually reach 1-look. With this system, if you couldn't 1-look the case, you wouldn't know which to algorithms to do and may not even get a 2-look. You could think about it for a while and come up with the 2 algs for the case, but this isn't good to do if your speedsolving. So along with reducing algs a bit and using algs that you personally like, you are getting rid of a step up to the 1-look.


----------



## Smiles (Apr 13, 2013)

elrog said:


> Doing a 1LLL would be just as easy/hard with any other 2-alg system. You would learn the cases and know which 2 algs to use for that particular case. Other 2-alg systems may require more algs, but they're not at all unlearnable because of alg count. Other 2-alg systems wouldn't have to have the need of learning every case because they can be done in 2-looks possibly providing a way to eventually reach 1-look. With this system, if you couldn't 1-look the case, you wouldn't know which to algorithms to do and may not even get a 2-look. You could think about it for a while and come up with the 2 algs for the case, but this isn't good to do if your speedsolving. So along with reducing algs a bit and using algs that you personally like, you are getting rid of a step up to the 1-look.



wut
i thought the entire point of this learning this method was that it only required you to know the first alg, then the second alg you could just see it.
i haven't actually looked at many of the cases, but to my understanding, for example, if you do one alg and the next COLL case is niklas, you're not gonna assume it's some special ZBLL case unless it's a special case that you would have already known.
and since it's using a set of algs that is considered "good" partly because everyone already knows them, it assumes that you already know how to identify CLL during OLL and whatever else, that being the only reason you would ever know these algs like niklas and a few easy OLLCPs.


----------



## UberStuber (Oct 29, 2013)

Here's a list of many of the '2nd look' algorithms organized by CLL case. After you do your first algorithm, you get one of these. Very easy to recognize. Once the whole 1st look set is organized there will be more algs to add.

https://docs.google.com/document/d/1f3vC8BTyrs_TyXn7SBYaQqGhzx4w5VbZrF1N8WaBEfU/edit?usp=sharing
Not sure if this is helpful.

edit: I'm missing a lot of algs, will add later tonight.


----------



## StachuK1992 (Oct 29, 2013)

Can you explain that table a bit more? I'm confused.


----------



## UberStuber (Oct 29, 2013)

So the general concept is to solve the whole LL with a combination of two easy algs. The first alg will bring the cube to a state that can be solved by one of the algs on the table I posted. Note that my table is currently missing quite a few algs, depending on how the 1st look is organized and which algs are picked. 

So, finish F2L, 1st look (still to be organized) perform first alg, 2nd look perform 2nd alg (table I posted), cube is done

I'm compiling the 'second look' algs just to show how easy recognition would be.


----------



## Kirjava (Jun 20, 2014)

So before Tempus came along with his alg wizardy I had actually been working on this system on and off.

The organisation system I had was good but failed because I applied it to the entire LL, it's harder to find patterns and improvements and generally not that great to learn in that way.

So I had the idea to use the same concepts for organisation, but split those into subsets. You can pick any subsets you like to do this, but I chose to reorganise by CLL because I learnt OLLCP by sorting by CLL.

Here's a general idea of the way things are organised: LL-A (I know the layout sucks, was a POC)

Then some very relevant material appeared in this thread which you might wanna read you get yourself up to speed.

Based on this information I created a two algorithm based LL solver. You can get it here;

2LL

State input is done via alg or a visual interface.

I made it so I can more easily find solutions of this type with various types of algorithm sets. The old way I was producing this information took way longer and this is more versatile. It should massively reduce time taken to produce subsets.

I'll add OLLCP support/kociemba/other stuff if people are interested. Would be interesting to make a more general LL solver but it's just for 2LL stuff now.

My next plan it to collaborate with Tempus to find the pool of algs best suited to this task, then use it.


----------



## FinnGamer (Jun 20, 2014)

Really great tool! Just tried out a few LLs I got in casual solving and was surprised how trivially they can be solved. Really looking forward to learnable categories


----------



## Dane man (Jun 20, 2014)

Kirjava said:


> Based on this information I created a two algorithm based LL solver. You can get it here;
> 
> 2LL
> 
> ...


This is fantastic. Though, being that the algs are already chosen for their efficiency, would it be possible to put them in order of number of moves when "solve" is clicked?

As for the method of memorization and organization, I would personally (after choosing the algs and combinations I want) memorize what each algs solves on it's own (the effects of each alg), then organize the combinations by the beginning alg with visual representations of the cases that are solved with it. If I were to memorize and/or learn to recognize the cases that are solved with each beginning alg (perhaps through some pattern recognition if possible), then I could simply recog, apply the beginning alg, then, knowing what I know about what each alg solves, apply the second alg, and I'm done. And an interesting thing is that within all of the cases for each beginning alg, you'll already have the combinations that are solved in one alg, so we won't have to worry about those.

Nice work!


----------



## Kirjava (Jun 20, 2014)

Dane man said:


> As for the method of memorization and organization, I would personally (after choosing the algs and combinations I want) memorize what each algs solves on it's own (the effects of each alg), then organize the combinations by the beginning alg with visual representations of the cases that are solved with it.



I have already outlined this idea as my main organisation concept and even implemented it. Trying this the first time I ran into a few problems that I believe can now be resolved.

I think with grouping, an improved alg set, and other improvements it will work a lot better. Hopefully Tempus will poop out a golden nugget if I feed him more alg groups and I can use that to create learnable and friendly documentation.


----------



## Dane man (Jun 20, 2014)

Kirjava said:


> I have already outlined this idea as my main organisation concept and even implemented it. Trying this the first time I ran into a few problems that I believe can now be resolved.
> 
> I think with grouping, an improved alg set, and other improvements it will work a lot better. Hopefully Tempus will poop out a golden nugget if I feed him more alg groups and I can use that to create learnable and friendly documentation.


Nice. So what kind of "golden nugget" are you looking for? Is he writing some more code to accomplish a certain task you've got in mind? Or are you hoping that the right alg groups will create a more user friendly pattern of combinations for memorization? Or both?


----------



## Kirjava (Jun 20, 2014)

Dane man said:


> Nice. So what kind of "golden nugget" are you looking for? Is he writing some more code to accomplish a certain task you've got in mind? Or are you hoping that the right alg groups will create a more user friendly pattern of combinations for memorization? Or both?



Minimum non-'forced' algs. As in, the higher percentage of algs that are specified by me in the alg pool the better.


----------



## irontwig (Jun 20, 2014)

Surely the ease of determining the first alg and the average quality/speed of the solutions is by far more important than the number of algs one needs to learn?


----------



## Kirjava (Jun 20, 2014)

irontwig said:


> Surely the ease of determining the first alg and the average quality/speed of the solutions is by far more important than the number of algs one needs to learn?



Of course. I'm talking about minimising the bad algs. Total alg count isn't important.


----------



## elrog (Jun 21, 2014)

The 2LL is very cool! Could you let the user input an alg set and see if it covers all LL cases, ZBLL cases, ZZLL, cases and so on? Then Anyone could pick their favorite algs.


----------



## Kirjava (Jun 21, 2014)

I could, but I'm pretty certain that anyone picking their favourite algs would not produce something capable of solving all cases.


----------



## Villyer (Jun 23, 2014)

Slightly technical question, how did you store the info for all of the possible LL cases? I figure you must have had some document or something with them all represented in a way a program could read. By chance is that something you would be willing to share? It would be a nice reference and I like making programs for things.


----------



## Kirjava (Jun 24, 2014)

Villyer said:


> Slightly technical question, how did you store the info for all of the possible LL cases? I figure you must have had some document or something with them all represented in a way a program could read. By chance is that something you would be willing to share? It would be a nice reference and I like making programs for things.



I'm not sure exactly what you mean. The program generates solutions for an LL itself each time you run it, they're not saved anywhere.

In other news, new stuff coming very soon...


----------



## Villyer (Jun 24, 2014)

Kirjava said:


> I'm not sure exactly what you mean. The program generates solutions for an LL itself each time you run it, they're not saved anywhere.=



I figured you had a way of documenting which LL case was which. So when the program gave an output like what alg pairs solved what cases, it would use that document to reference which case was being solved (by that specific list of pairs).


----------



## Kirjava (Jun 24, 2014)

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


----------



## vcuber13 (Jun 24, 2014)

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 (Jun 24, 2014)

[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 (Jun 24, 2014)

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


----------



## PhillipEspinoza (Aug 14, 2014)

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 (Aug 14, 2014)

PhillipEspinoza said:


> 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.



PhillipEspinoza said:


> 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.



PhillipEspinoza said:


> 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.



PhillipEspinoza said:


> 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 (Aug 14, 2014)

PhillipEspinoza said:


> 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 (Aug 14, 2014)

Stefan said:


> 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 (Aug 14, 2014)

supercavitation said:


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



No I didn't.


----------



## supercavitation (Aug 15, 2014)

Stefan said:


> No I didn't.



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


----------



## IRNjuggle28 (Aug 15, 2014)

Stefan said:


> 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.


supercavitation said:


> 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. 


PhillipEspinoza said:


> 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 (May 6, 2016)

Kirjava said:


> 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.
> 
> ...


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 (May 9, 2016)

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


----------



## Teoidus (May 10, 2016)

Has Kirjava just vanished recently? This looked interesting.


----------



## Lars Petrus (Feb 23, 2017)

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 (Feb 23, 2017)

Lars Petrus said:


> 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.
> 
> ...


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 (Feb 23, 2017)

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 (Feb 23, 2017)

Lars Petrus said:


> Oh yeah, we even talked about the combo thing!
> 
> The ideal tester would build their own combo alg set and try to use it.
> 
> ...


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 (Feb 23, 2017)

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 (Feb 23, 2017)

Lars Petrus said:


> 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.


----------



## psi (Feb 25, 2017)

Lars Petrus said:


> 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.
> 
> ...



This is so nice! I played a little with the public part and it's really fun to explore the CO-CP-EO-EP combos.
Good job!
Sad I can't access the rest as I don't have a WCA ID. Any way to grant access in another way? You can pm me.

"Show" buttons are not working for me (not showing anything), also the FMC part is looking like it's only displaying "text". Am I missing something?

Also can I ask you how you developed the site (tech tools) ?


----------



## Lars Petrus (Feb 26, 2017)

It's hard to open that part up to non WCA ID users they way things are built now, sorry.

I'm *very* interested in how the "Show" buttons fail! If you can get to the Javascript console in your browser, there are probably error messages there that I want to see!

This is a Ruby on Rails project. The 47 million algs were generated by Tom Rokicki, though he is not exactly a technology. The images are SVG, which I've learned a _lot_ about doing this.

PS. The FMC section is not very developed, but you should see animated Roofpig cubes there!


----------



## psi (Feb 26, 2017)

Lars Petrus said:


> It's hard to open that part up to non WCA ID users they way things are built now, sorry.
> 
> I'm *very* interested in how the "Show" buttons fail! If you can get to the Javascript console in your browser, there are probably error messages there that I want to see!
> 
> ...



Ok, thank you. Then I hope you will open to the public also the rest ASAP!
This is a firefox screen cap of the console after I clicked on "show" (also on chrome it does not work). Some errors were present before (on page load) but I left here only the error following the action.


----------



## Lars Petrus (Feb 27, 2017)

It should work now!


----------



## psi (Feb 28, 2017)

Lars Petrus said:


> It should work now!


Yep!
But still one small glitch on firefox: once i click on the title to drag the frame around (cross cursor appears) I can't release it in the sense that it sticks to the cursor (frame moves with it). Only way to release it is to press ESC to make the frame disappear. If I press "show" again the frame stays sticked to the cursor, following it. Refreshing the page gives back an unsticked frame (hope it is clear).
No problems on Chrome.


----------

