Here's an idea I had:
maybe we can do Roux LSE with 2 looks.
the first look is what I call Shifted EOLR.
it's like standard EOLR where you solve EO and insert the LR edges to DF DB, but in this algset, you can ignore the ending position of the canters.
what do I mean?
well, let's explore what a single M move does.
to the centers on the M slice:
if they are LR edges, they are flipped (obviously). if they belong in the M slice, nothing changes in their orientation. why? because the new U center has changed and their thus their relation to the U center doesn't change even though they physically flipped.
for edges not on the M slice (UL / UR):
if they are the LR edges, nothing happens to them (obviously). if they are M slice edges, they get flipped, since the new U center has changes.
obviously, if UL and UR don't have the same kind of piece the logic still applies the same. to summarize the effects of a single M move on the edges:
on the M slice:
if LR edge - flip
if Medge - no change
on UL / UR:
if LR edge - no change
if Medge - flip.
with that logic, we can really reduce EOLR algorithms' movecount. some of the algorithms only have 1 move!
the main problem is recognition, but if you standardize the centers before LSE, as it is usually done anyway, nothing changes about that.
we can end it here, call it a day.
we just do DFDB recognition, insert the LR edges and finish with 4c (though the centers might be off by an M or an M' move. it doesn't add any moves).
from my research, Shifted EOLR has the same amount of cases as regular EOLR, since the edge flip technically doesn't care about the centerers as long as you follow the rules for orientation for each M move.
but, I have thought about taking it a step further. I'm pretty sure it's not worth it, but still:
what about finishing the rest with one algorithm? that way you can guarantee you get the best solution, never having a bad dots case ever.
so, I generated the algorithms using Trangium's Batch solver (sorry if I'm writing it wrong).
they are pretty good, but most of them are just "insert LR, do 4c". this proves that this algorithm set is not super good, but it can still save a couple of moves.
just like DFDB recognition is enough for 4c, you just need to know the color of F sticker in FR (L or R), the recognize using the UF edge and the shape of the U layer edges (which only requires 1 extra sticker, the one that UF has on U). and the centers. that's just 5 sticker recognition, 6 if you want to always look at UF and UR.
now, while I love the idea, it has some drawbacks:
1. Shifted EOLR can be confusing and have hard recognition, making it a tool requiring high skill.
2. EOLR isn't really an algorithm set, it's a mindset to adopt and use intuitively usually. it can be done algorithmically (108 algorithms or 128 cases, not too sure), though. Shifted EOLR can be done intuitively with the M slice logic I described, but it's very, very hard.
3. The algset to solve the cube after Shifted EOLR is generated, but it might have too much cases that I haven't reduced properly. also, most of them are just insertion to 4c, making it not super worth it to learn.
still, Shifted EOLR -> RL6EP (reduced last 6 edges permutation) is, mathematically, at most the same amount of moves as standard EOLR -> 4c, and it usually requires less moves. If you look at it from an algorithmic standpoint, the same applies, since every EOLR algorithms can be a Shifted EOLR algorithm, while not every Shifted EOLR algorithm can be an EOLR algorithm, and the same goes for RL6EP and insertion->4c.
so, please do tell me your thoughts. I'm aware this isn't much of a friendly, beginner method, but I think it can have a lot of potential.
I'll be attaching the files with algorithms and others (one of them is an index.html file, so just click on it and it will open up. please don't trust random code you see on the internet before inspecting it with a file checker and all the other safety precautions), so you may see them yourselves.
please do ask me anything and share your thoughts.
