Developing a better LL system

[AHornbaker]

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]

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]

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]

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]

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]

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

 

[UberStuber]

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]

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]

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]

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.

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]

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]

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]

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]

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]

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]

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]

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

 

[Villyer]

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]

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]

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