Cassiopaia
Member
Hi everybody.
Today i will share my flip algorythm aproach with you. As usual, I believe I was the first to come up with the idea, but I can't guarantee. The cubing world is big.
Here's how it works: Whenever you want to apply an algorythm on both sides of the cube, you would normally have to flip the cube upside down to work on the other side. Some use cases are, for example: Some columns first and corners first methods, or when you do "dirty" pairs in CFOP where the corner is just any bottom layer corner (in any orientation) to increase lookahead and save turns by having more options to choose from (lucky cases and even presolved pairs happen way more often).
Actually, you may build that flip into the algorythm itself which works surprisingly well and costs approximately the same and in some cases even fewer turns compared to the non-flip version. I believe it is like turning a car around: Drive out of a parking space, turn it around and drive back in. It's just easier to drive out of one and right into another parking space.
Here are two examples:
For ELL algorythms, simply create the ELL algorythms (for example with cube explorer), but then use one that ends with x2 or z2 and just don't do that flip. The algorythm has turned the cube around in some way and you just don't turn it back. Easy.
And for CLL flip algorythms, create cll algorythms but "lie" to the programm an R2 or L2 would be needed, and the programm will build an algorythm around that requirement. It's a bit tricky and hard to explain, but you're smart, you'll figure out. I may also help when you have a use case for those algs. Another approach would be to simply choose an algorythm that ends with R2 L2 and just refuse to do those, or exchange an R2 with an L2. Something like that.
Pure orientations or permutations are also flip algorythm-able. And of course you may also mix, like ELL flip, followed by normal OLL and PLL. And double using ZBLL to save turns two times? Yep!
Due to parity, there are more cases compared to the non-flip versions. The movecount is, as said, surprisingly low given the extra task the alg has to do. You'll get a cube turn almost for free! Whenever you need a cube turn after an algorythm, just build it into it in a move efficient way. That's the flip algorythm approach!
Also, using flip algorythms is actually really cool and fun
Feel free to use this aproach in any method where it's useful. The only thing i ask for is giving me credit (unless it turns out I'm not the frist one having that idea)
Have fun, and may the lookahead be with you!
Today i will share my flip algorythm aproach with you. As usual, I believe I was the first to come up with the idea, but I can't guarantee. The cubing world is big.
Here's how it works: Whenever you want to apply an algorythm on both sides of the cube, you would normally have to flip the cube upside down to work on the other side. Some use cases are, for example: Some columns first and corners first methods, or when you do "dirty" pairs in CFOP where the corner is just any bottom layer corner (in any orientation) to increase lookahead and save turns by having more options to choose from (lucky cases and even presolved pairs happen way more often).
Actually, you may build that flip into the algorythm itself which works surprisingly well and costs approximately the same and in some cases even fewer turns compared to the non-flip version. I believe it is like turning a car around: Drive out of a parking space, turn it around and drive back in. It's just easier to drive out of one and right into another parking space.
Here are two examples:
For ELL algorythms, simply create the ELL algorythms (for example with cube explorer), but then use one that ends with x2 or z2 and just don't do that flip. The algorythm has turned the cube around in some way and you just don't turn it back. Easy.
And for CLL flip algorythms, create cll algorythms but "lie" to the programm an R2 or L2 would be needed, and the programm will build an algorythm around that requirement. It's a bit tricky and hard to explain, but you're smart, you'll figure out. I may also help when you have a use case for those algs. Another approach would be to simply choose an algorythm that ends with R2 L2 and just refuse to do those, or exchange an R2 with an L2. Something like that.
Pure orientations or permutations are also flip algorythm-able. And of course you may also mix, like ELL flip, followed by normal OLL and PLL. And double using ZBLL to save turns two times? Yep!
Due to parity, there are more cases compared to the non-flip versions. The movecount is, as said, surprisingly low given the extra task the alg has to do. You'll get a cube turn almost for free! Whenever you need a cube turn after an algorythm, just build it into it in a move efficient way. That's the flip algorythm approach!
Also, using flip algorythms is actually really cool and fun
Feel free to use this aproach in any method where it's useful. The only thing i ask for is giving me credit (unless it turns out I'm not the frist one having that idea)
Have fun, and may the lookahead be with you!
