Is 1LLL possible?

[TreacherousToast]

To create the database you would have to have cube explorer automatically running through all the cases 24/7

 

[Metallic Silver]

1LLL must be possible.
If a person can know full ZBLL, RLS, ZZCT, and OLLCP, then it's possible for a person to learn 1LLL.

 

[DGCubes]

To create the database you would have to have cube explorer automatically running through all the cases 24/7

Well, there's this.

 

[xyzzy]

Well, there's this.

There's also this and this (although these algs are not optimised for fingertricks at all).

 

[obelisk477]

To create the database you would have to have cube explorer automatically running through all the cases 24/7

Lars Petrus' database contains all algs for all last layer cases that are 17 moves are less. Which I'm pretty sure that no LL case requires 18+ moves

 

[cuBerBruce]

Lars Petrus' database contains all algs for all last layer cases that are 17 moves are less. Which I'm pretty sure that no LL case requires 18+ moves

In fact, all last layer positions can be solved in 16 moves (FTM) or less, including AUF. I gave the distribution here.

 

[Martin Orav]

Is it possible (in theory) to recognise 1LLL by looking at the top layer and two adjacent sides?

 

[AlphaSheep]

Is it possible (in theory) to recognise 1LLL by looking at the top layer and two adjacent sides?

Yes. OLL can always be recognised from the top and two sides, you have enough info to work out CP, and just two edges is enough to work out EP if CP is known.

 

[Gold Cuber]

What is 1LLL?

 

[cuber314159]

What is 1LLL?

1 look last layer

 

[Escher]

Possible? Sure.

The problem is the relationship between case set size, algorithm uniqueness, and recognition factors. PLL reduces via AUF to a small number of cases (from technically speaking, 72), case solutions may use a decent number of mirrors/inverses, and can be recognised using knowledge of only 6 sticker values relationships from any AUF. The algorithms themselves tend to be quite distinct - or if not distinct, intuitively relatable.

Recognition time involves the comprehension of the case, pulling a distinct 'macro exec case' for the algorithm from a kind of memory, and execution relies on another kind - procedural memory.

At the basic level, maintenance of the procedural memory gets more and more time demanding as the number of unique algorithms rises. Attaching this procedural memory firmly to the correct cases has another (but related) time demand. A confounding factor is solution similarity - the larger the solution set, the more demanding it is to maintain the relationship of x case 'macro memory' to x case procedural memory when x and y case are near-identical.

One level higher, the complexity of sticker relationships to case identification increases the more powerful a system becomes, and so maintenance demand increases. Some minimum n of stickers to establish case uniqueness must be increased. Now maintenance of the connection between macro and procedural must be balanced alongside maintaining the relationship between recog state and macro memory. Managing this trade-off between the two factors is by itself another demand.

All of these demands create trade-offs for you, the human. When comparing two systems, we list the presupposed qualities, and this stage is where most cubers theories or systems live and die. The more important (and harder to measure) factor is that they must show a distinct advantage in the real world, in general. Otherwise speed advantages can be attributed to individual qualities, rather than the system itself having a quantifiable, proven advantage.

The currently-conceived 1LLL systems are still in this latter stage of theory-testing. I'm not sure if they will pass the empirical demands. One option that was explored a few years ago by Kirjava was the idea of generating solutions for all LL cases from two short-length OLL algorithms, plus one setup move in the chain. This solved some elements of the macro-memory problem rather succinctly. The next problem was to figure out how to establish recognition in a maintenance-efficient manner. Unfortunately no simple solutions were apparent - grouping cases by initial OLL didn't reveal higher-order patterns (except for the obvious fact that each OLL applies a fixed transformation). Nor did deep intuitive or mechanical analysis. 1LLL, outside of pre-processing for certain cases in the F2L stage - as ZBLL does - is simply massive.

Because of these research problems - both for figuring out the maintenance problem, and the uncertainty of real-world advantages - there are significant issues with pure 1LLL.

My personal view on the topic is that we take a less pure approach towards systems. Measurement of single solves is an impure test of 'speed', and the paradigm of avg5 selects for certain ways of thinking which may not be ultimately beneficial. Ideally we should seek to increase the *incidences* of 1LLLs, not tyrannically enforce them. We should also look to reduce redundant sticker recognition, as well as the number and relationship of stickers to apprehend at any one instance.

The pragmatic approach is already evidenced as successful with a close reading of the very, very fastest CF(OP) cubers. Generally speaking PLL has already been recognised during the OLL execution so that the entire LL is executed in (apparently) one 'instance'. Recognition has been integrated with execution at this level. Also, typically some pre-processing for better LL cases has been done during F2L. The move cost for doing so can be very low (or even free) if one is already at a certain speed and sophistication of lookahead.

The desire for methodological purity is a seductive one. Instead, I feel like formalising the construction of a general approach may be the next level of advancement in solving the 1LLL problem. There are many options for hybridising existing systems and we currently lack a rationalised guidebook for the better options.

My loose conception of what this looks like; heuristics for pre-processing in the F2L stage (efficiently preserving and increasing late-stage partial solutions as they appear in earlier stages); increasing the number of available opportunities to smoothly include full orientation with the end of the F2l; exploiting un-used macro storage for higher-level cases; training PLL recognition mid-OLL; and improving intuition for avoiding worst-boundary cases efficiently (such as diagonal corner PLLs).

Of course, this is not to say that theoretical research and exploration is a bad thing, necessarily. Simply there is a lot of low-hanging fruit, providing we choose the right perspective. Focusing efforts on a particular branch for it's 'pure qualities' isn't ipso facto the right method for increasing the harvest.

 

[cuber314159]

while I think that it is possible and viable to do 1lll it may be better for speed solving to be able to recognise OLL and then execute the OLL but while executing the OLL recognise the CP + EP of the OLL case and then recall what PLL to do straight away, this is what caused feliks to get his 4.73 single, by knowing the PLL before doing it and if this could be done every solve then sub-6 averages could be possible within the next year or two.

 

[Rcuber123]

while I think that it is possible and viable to do 1lll it may be better for speed solving to be able to recognise OLL and then execute the OLL but while executing the OLL recognise the CP + EP of the OLL case and then recall what PLL to do straight away, this is what caused feliks to get his 4.73 single, by knowing the PLL before doing it and if this could be done every solve then sub-6 averages could be possible within the next year or two.

I'm pretty sure feliks does this at least half the time.

 

[shadowslice e]

while I think that it is possible and viable to do 1lll it may be better for speed solving to be able to recognise OLL and then execute the OLL but while executing the OLL recognise the CP + EP of the OLL case and then recall what PLL to do straight away, this is what caused feliks to get his 4.73 single, by knowing the PLL before doing it and if this could be done every solve then sub-6 averages could be possible within the next year or two.

This is ROLL and I'm pretty sure quite a few top solvers do it in many of their solves already. 1LLL is still faster though.

 

[One Wheel]

I need to stop reading threads like this. It makes me want to learn 1LLL, and maybe megaminx 1LLL someday, but I still have about 40 OLLs and 7 OCLLs plus mirrors for megaminx left to learn.

 

[Abram Lookadoo]

i have found a way to reduce 1lll alg count to 1289

you preform an M2 S2 , then you auf and adf, preform 1/1289 algs, auf and adf, then preform M2 S2

 

[shadowslice e]

i have found a way to reduce 1lll alg count to 1289

you preform an M2 S2 , then you auf and adf, preform 1/1289 algs, auf and adf, then preform M2 S2

But reforming M2 S2 will really slow down the solve.

 

[ComputerGuy365]

It's called ZBLL, isn't it?

 

[Underwatercuber]

It's called ZBLL, isn't it?

*facepalm
Please just do everyone here a favor and educate yourself here:
https://www.speedsolving.com/wiki/index.php/ZBLL

 

[AlphaSheep]

It's called ZBLL, isn't it?

ZBLL needs all edges to be oriented. Full 1LLL is about 8 times larger.