# Floating buffers discussion



## ottozing (Feb 11, 2016)

For a while now, I've thought about the idea of floating buffers for 3BLD, but at best I've only been able to solve random isolated 3cycles outside of the buffer just from pure 3x3 speedsolve style recognition. After Gianfranco's recent official 21.5x where he solved a few edges before solving corners first like usual, I saw a comment mentioning floating buffer. However, when I looked at the reconstruction I assumed he was just solving a 3cycle outside of the buffer the same way I would from time to time. Earlier today, I had a bit of a light-bulb moment about the whole thing and might have figured out how Gianfranco might do it (I'm yet to ask him), but at the very least definitely figured out how I could start doing it. This new way might not be as fast as raw recognition for something like a U perm of edges that just sticks out immediately, but it's not far off AND can handle more types of cycles outside of the buffer at least in theory. Parity and twisted pieces/buffers being solved but twisted early on makes this way more confusing though, which is why I'd like to see discussion from other people 

(My letter scheme because too lazy to write this in speffz, I'll be scrambling white on top red on front).



Spoiler: Example solve



R2 D2 L B2 D2 U2 R D2 B2 D2 L' U' L2 F R' B2 L B F D2 U 

Corner memo (6'): AN LH UY then corner twist

U' L D2 L' U L D2 L'
U' L' U R U' L U R'
D2 l U' R U R' l' D2 R l U' R' U l'
U R U' R' U R U' L2 U R' U' R U R' U' L2

Edge memo before changing buffers: MH VR PO

U' M' U' M U' M' U' M
M' U' M D M' U M D'
M U' L U M U' L' U M2

Edge memo changing buffer to DR (y rotation): RF then flip edge

y
u' M' U' R U M U' R' U u
M' U2 R2 U R' U' R' U2 r U R U' r2' 
y'

If you're wondering how I knew the 2nd buffer would be flipped and not the first one, when memoing my first cycle I saw that I shot to the yellow of the yellow red edge, meaning it would be solved. Similarly, for my second cycle with a yellow blue buffer instead of yellow red, when I got to F I shot to a blue sticker, meaning that piece would be flipped. Notice how you can do the entire "Edge memo changing buffer to DR" solution at the start of the solve 



That's about all I have to say at the moment. After a lot of thinking I feel like this probably won't be useful beyond the very convenient cases where you don't have parity and end up in a new cycle after an even target. Even then, if you use floating buffer the same way I did in the example but for corners and both buffers end up twisted, you'd need some sort of extra recognition system on top of that to account for it.


----------



## rock1313 (Feb 11, 2016)

Very interesting Jay, I've actually done it in some solves where there are lots of new cycles. If we want to constantly put floating buffers our solves, it would require more thinking during a bld solve when we want to make memoing brainless as possible. For example, if you have a flipped edge somewhere like in your example scramble, it will take a bit of time to figure out if the other flipped edge will be your buffer or your floating buffer (corners would be even worse). It wouldn't be much time to figure it out but you need to do some extra thinking when you should be thinking about your memo or you will forget it.

But seriously, if you train your brain to make floating buffers as brainless as possible during an easy no parity scramble, you are going to be ahead of everyone else.


Memo corners, Memo edges, Memo 3 cycle edges with floating buffer -> Solve 3 cycle edges with floating buffer, Solve edges, Solve corners. That would be insanely fast!!!


----------



## Daniel Lin (Mar 11, 2016)

I don't understand how the comm U' M' U' M U' M' U' M works. can you please explain it?


----------



## ottozing (Mar 11, 2016)

Daniel Lin said:


> I don't understand how the comm U' M' U' M U' M' U' M works. can you please explain it?



It's one of those cases where you should really just learn it as an algorithm. The way it "works" is by taking [y ; [U , M D M'], replacing all the D moves with Dw moves, and finally rewriting the alg so it's MU gen. Cases like M' U' M U2 M U M' U2 work the exact same way!


----------



## Daniel Lin (Mar 11, 2016)

ok, i see. Very cool

about your floating buffer idea, I've come up with some algs for cases with double 2 swaps. These are for when your main buffer is DF and your new buffer is DR

Set up your last DF target to UF and then apply and alg depending on your DR target 

For example
UR R2 F2 R2 F2 R2 F2
DL z2 M U M2 U2 M2 U M'
FL z2 R M U M2 U2 M2 U M' R'
BL z2 r' U M2 U2 M2 U r
UL z2 r' R' U M2 U2 M2 U R r
LD z2 M' U (R U R' U' M' U2 R' U' R2 U' r' U R' U R) U M
LF z2 r U (R U R' U' M' U2 R' U' R2 U' r' U R' U R) U r'
RF x U2 R U' (R U R' U' M' U2 R' U' R2 U' r' U R' U R) U' R' U2 x'


I don't know of an intuitive way to figure these out like commutators. most of the ones above are all H perm setups are very inefficient. These are just examples to give people an idea. 

you might think BLD is slower with parity/twisted corners/ flipped edges, but this is not true. With double two cycles and parity algs, you don't have to break into many cycles and this reduces move count. in Maskow's 16.29 UWR he did a T perm, which made the solve much faster. Similarly, if we use double two cycles or switch to a new buffer we don't have to waste moves shooting to a new piece and shooting back to it at the end. As for flipped edges and twisted corners, there are algs that solve 3 cycles, or even double 2 cycles as well as flip edges. such as M' U' M' U2 M' U M U' M' U2 M U M2. The only problem though of course, is it becomes way more complicated when bld is supposed to be brain dead


----------



## ottozing (Mar 11, 2016)

Daniel Lin said:


> ok, i see. Very interesting
> 
> about your floating buffer idea, I've come up with some algs for cases with double 2 swaps. These are for when your main buffer is DF and your new buffer is DR
> 
> ...



For 3 cycles plus a flipped edge, there's even intuitive stuff like M' U' R2 U' M' U R2 U' M2 U2, although I'm definitely not at the point where I'm comfortable using those and have yet to explore it further. 

As for floating buffers, I've been using them in solves whenever I can tell during memo that I have a pure 3 cycle outside of the buffer and it's... decent? Sometimes I feel like it's not worth it, but whenever I can just look at the 3cycle and know how to solve it through pure visual recognition, it's super good. I'm just hoping that through practicing that at home I can get to a point where I'm visually recognizing a lot of different types of 3cycles (mainly edges are what I struggle with, corners are usually some type of COLL I'm familiar with or an 8 mover that doesn't take long to figure out).


----------



## Daniel Lin (Mar 11, 2016)

how did you come up with M' U' R2 U' M' U R2 U' M2 U2?


----------



## pinser (Mar 23, 2016)

Another idea:

*My buffers: DF and ULB*
*I solve parity by solving last target M2 style then doing D' L2 D M2 D' L2 D then solve last corner target OP style*

Memo corners:
3 possibilities:
1. Last target is buffer
Floating buffer is not needed
2. Buffer is an odd target
This means parity. Use floating buffer. After solving with floating buffer, go back to original buffer and solve the single target.
3. Buffer is an even target
Floating buffer. Either U, U’, or U2 (or rotate or whatever). Adjust memo accordingly. 
(Only use floating buffer once. If buffer solved when using floating buffer, just break into another cycle)

Memo edges:
Floating buffer only if no parity and even target. 

Execution: 
Solve edges, solve corners, EPLL if parity.

I haven't played around with it much, but I still think any kind of floating buffer slows down memo too much and isn't worth it.


----------

