• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

objectively optimal L5C?

  • Thread starter Thread starter Deleted member 36445
  • Start date Start date
D

Deleted member 36445

Guest
So I was thinking...

Sexy method ends with L5C and it deals with brute forcing sexy moves until last buffer is solved.
It may happen "parity" when two corners are permuted correctly but oriented wrong. It may need setup move to make them the same layer and then undoing the setup at end, obviously

What would be the advanced way to solve l5c? Maybe two 3bld comutators? how to learn?
 
By applying the sexy moves in a different order, it's always possible to avoid getting buffer-twist, but I don't think anyone's ever figured out a reasonable way of doing it (besides e.g. solving orientation first, then permutation, which technically works but is inefficient).

"Full" L5C has too many cases to be reasonable to learn algs for. You can break it down into these categories:
- pure twists: few enough cases (24) that you can learn all of them, all RU 2-gen-able (although you'd prefer RUS/RUL/etc. algs for a few of them)
- (non-pure-twist) L3C: 3-cycle commutator/alg
- (non-pure-twist) L4C: two comms (use first 3-cycle comm to solve one corner and ensure it doesn't leave a pure twist), or set up to ZBLL
- 5-cycle: two comms (use first 3-cycle comm to solve two corners)
- 2 twisted corners + normal 3-cycle: comm then pure twist alg
- 2 twisted corners + twisted 3-cycle: ?? (three comms?)
- 1 twisted corner + two possibly-twisted 2-cycles: ?? (three comms?)

Last three categories would probably benefit the most from learning 1-look algs, since they're the ones that need 3 3-cycles to solve.

(edit: I can't count; I calculated the number of cases wrongly originally and have since edited it out)
 
Well the optimal way would be learning all 615 ish algs for 1 alg l5c.
but that would be equivalent to zbll or 1LLL on a greater extent right?
because learning so many algs would not be so good as learning an intuitive way with less algs.
but I may have worded it wrong
By applying the sexy moves in a different order, it's always possible to avoid getting buffer-twist, but I don't think anyone's ever figured out a reasonable way of doing it (besides e.g. solving orientation first, then permutation, which technically works but is inefficient).

"Full" L5C has too many cases to be reasonable to learn algs for. You can break it down into these categories:
- pure twists: few enough cases (24) that you can learn all of them, all RU 2-gen-able (although you'd prefer RUS/RUL/etc. algs for a few of them)
- (non-pure-twist) L3C: 3-cycle commutator/alg
- (non-pure-twist) L4C: two comms (use first 3-cycle comm to solve one corner and ensure it doesn't leave a pure twist), or set up to ZBLL
- 5-cycle: two comms (use first 3-cycle comm to solve two corners)
- 2 twisted corners + normal 3-cycle: comm then pure twist alg
- 2 twisted corners + twisted 3-cycle: ?? (three comms?)
- 1 twisted corner + two possibly-twisted 2-cycles: ?? (three comms?)

Last three categories would probably benefit the most from learning 1-look algs, since they're the ones that need 3 3-cycles to solve.

(edit: I can't count; I calculated the number of cases wrongly originally and have since edited it out)
thanks for the effort put on that post. maybe I can create an L5C example solve thread later. that could make people develop a method further.
 
Last edited by a moderator:
Coincidentally I have a few things in development. It has been my big project for three months now and should be finished soon. L5C, a couple of new L5C concepts which improve L5C, additional combinations within those, an analysis of L5C and the various techniques, and a planned follow up post analyzing related full 3x3 methods. It has been a lot of work, but is something that I think is necessary and was missing from the community. If you are in the development Discord server, you may have seen me talk about it.
 
By applying the sexy moves in a different order, it's always possible to avoid getting buffer-twist, but I don't think anyone's ever figured out a reasonable way of doing it (besides e.g. solving orientation first, then permutation, which technically works but is inefficient).

"Full" L5C has too many cases to be reasonable to learn algs for. You can break it down into these categories:
- pure twists: few enough cases (24) that you can learn all of them, all RU 2-gen-able (although you'd prefer RUS/RUL/etc. algs for a few of them)
- (non-pure-twist) L3C: 3-cycle commutator/alg
- (non-pure-twist) L4C: two comms (use first 3-cycle comm to solve one corner and ensure it doesn't leave a pure twist), or set up to ZBLL
- 5-cycle: two comms (use first 3-cycle comm to solve two corners)
- 2 twisted corners + normal 3-cycle: comm then pure twist alg
- 2 twisted corners + twisted 3-cycle: ?? (three comms?)
- 1 twisted corner + two possibly-twisted 2-cycles: ?? (three comms?)

Last three categories would probably benefit the most from learning 1-look algs, since they're the ones that need 3 3-cycles to solve.

(edit: I can't count; I calculated the number of cases wrongly originally and have since edited it out)
Or you could place an oriented U-layer corner in UBR and do an R to reduce the number from 614 to 42(tldr: you can do conjugated CLL)
(if there are no oriented U-layer corners then you just orient one using 3-move triggers)
 
Or you could place an oriented U-layer corner in UBR and do an R to reduce the number from 614 to 42(tldr: you can do conjugated CLL)
(if there are no oriented U-layer corners then you just orient one using 3-move triggers)
indeed
you should only preserve edges, right?
EDIT: what about this? https://www.speedsolving.com/wiki/index.php/Last_Four_Corners
EDIT2: where can I find an l5c scrambler?

EDIT3: I was thinking about this: after f2l-1 you can solve eo+last edge, then last f2l corner+ ep, and the last 4 corners
 
Or you could place an oriented U-layer corner in UBR and do an R to reduce the number from 614 to 42(tldr: you can do conjugated CLL)
You can reduce the number of algs to learn a lot by using setup moves, but:
(i) 1-move setups are mostly okay, but 2-move or longer setups means you're adding 4+ moves to the total move count.
(ii) I'm not convinced that when it comes to something as complicated as L5C, you can easily recognise good setup moves to use on the fly. The alternatives are to memorise the setup moves up front or use worse but more systematic setup moves.

Your suggestion (as written) does not reduce to CLL (43 cases); it does not even reduce to last-layer L4C (86 cases); it reduces to the subset of L5C with the D corner oriented (still ~400 cases total).
 
I have 2 ideas for this:
1. Reduce to pure 3 cycle w/ one alg, then solve.
The kind of alg required for each "case":
5c - 3 cycle
5t - learn all pure flip algs for 5t (24)
3c2t - pure twist 2 corners
2c2c1t - my second idea may be better here

2. Reduce to EP solved TTLL+ (as in zzoomer's LSLL method), then solve
We do this with an alg that puts U corner at DFR, while creating a TTLL+. Then it can be solved.
 
You can reduce the number of algs to learn a lot by using setup moves, but:
(i) 1-move setups are mostly okay, but 2-move or longer setups means you're adding 4+ moves to the total move count.
(ii) I'm not convinced that when it comes to something as complicated as L5C, you can easily recognise good setup moves to use on the fly. The alternatives are to memorise the setup moves up front or use worse but more systematic setup moves.

Your suggestion (as written) does not reduce to CLL (43 cases); it does not even reduce to last-layer L4C (86 cases); it reduces to the subset of L5C with the D corner oriented (still ~400 cases total).
Sure, you can be technical about cases and say that because there can be one of four U layer corners used for the R turn or that, imagining you are setting up a case for example purposes, the corners currently on the U layer can be in one of four AUFs before applying the inverse of the algorithm. But this technique does reduce to only 42 algorithms. That really is all the solver needs to learn. CCLL wiki page. And, using ATCRM in my signature, it only requires the user to know 83 patterns to be able to recognize all cases. So nowhere near 614 or even 400 algorithms or patterns.
 
Sure, you can be technical about cases and say that because there can be one of four U layer corners used for the R turn or that, imagining you are setting up a case for example purposes, the corners currently on the U layer can be in one of four AUFs before applying the inverse of the algorithm. But this technique does reduce to only 42 algorithms. That really is all the solver needs to learn. CCLL wiki page. And, using ATCRM in my signature, it only requires the user to know 83 patterns to be able to recognize all cases. So nowhere near 614 or even 400 algorithms or patterns.
I'm assuming Filipe was asking in the context of a method similar to 8355 where solving the last five corners is the very last step, and everything else has to be preserved. In this case, you can't just freely do AUFs; you need to solve the corners with respect to the already-solved edges. It is impossible to conjugate a case with five unsolved corners into something with only three or four unsolved corners.

Am I missing something here?

3cfdda84008dda8c796fc22b8e0924b720eca679

edit: The hash:
Code:
$ echo 'inb4 someone is too obsessed with their own methods that they think everything has to be about them. you think I like taking snark ("be technical" as if what I said was only a technicality)? I'\''d rather be on the giving end.' | sha1sum
3cfdda84008dda8c796fc22b8e0924b720eca679 *-
I called it. I so called it.
 
Last edited:
I'm assuming Felipe was asking in the context of a method similar to 8355 where solving the last five corners is the very last step, and everything else has to be preserved. In this case, you can't just freely do AUFs; you need to solve the corners with respect to the already-solved edges. It is impossible to conjugate a case with five unsolved corners into something with only three or four unsolved corners.

Am I missing something here?

3cfdda84008dda8c796fc22b8e0924b720eca679
I think you are correct.

nice spoiler
 
I'm assuming Filipe was asking in the context of a method similar to 8355 where solving the last five corners is the very last step, and everything else has to be preserved. In this case, you can't just freely do AUFs; you need to solve the corners with respect to the already-solved edges. It is impossible to conjugate a case with five unsolved corners into something with only three or four unsolved corners.

Am I missing something here?

3cfdda84008dda8c796fc22b8e0924b720eca679
The case reduction can still be done, just not as easily. With additional techniques such as algorithm unions, additional algs which swap out the trapped corner (moving further away from the reduction goal), or longer setups (undesired of course). Or, depending on the situation, nothing new at all. Such as when there is a corner in its correct position. In this case it can be reduced to L4C or twisty L4C with just the single move.

But yeah, when you have solved edges to deal with it is all more complicated. Versus L5C in other methods where you are much more free to use additional techniques.
 
Back
Top