• 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.

Columns First - underestimated method?

If it's fast, it's fast. And PLL is fast. I'm saying that I think it's possible there are fast alternatives that better fit the theme of a method or make the method more its own thing. Or at least wish more people were spending time searching for these alternatives.
Remember, though, I based this off a method from Kenneth that did just that - he used CLL for the corners and then did L5EO/L5EP. I added some more little optimizations in the intuitive steps but I do think that making it more Fridrichy was an improvement, even if it was moving a little away from the 'theme' of the method. Kinda like how the blocks in Roux are a huge improvement over that CF method where you solve ledge+redge pairs.
 
I looked at a bunch of methods before, and saw this one as one similar to Roux, like Corners First.
I'm no Roux expert (I don't use it), but I think Roux is definitely better.

Some D edges in Roux can be eliminated during inspection, making look ahead much easier, and then only 2 D edges will remain unsolved the rest of the time, but you see them while doing M turns anyway.
In columns first, after making the columns, not only is it harder to look ahead during the 4 pairs because of D edges, you'll have to return to the D layer after making the columns. Plus, it seems to take a little more thinking since it has so many steps.

And with CFOP, D edges are all completed during F2L, and OLL and PLL have extremely fast easy recognition and execution.
Overall, CFOP is just less intuitive, and what's great about that is the only improvised part (the cross) is thought up during inspection.
 
I love how you're all focusing on the order of steps and other silly things that hardly make a difference when the real problem is the movegroups being used.
 
Also, EO in ColF is awkward to do.

As I said, movegroup is awkward especially for EO where its MSU. <M,S>isn't too bad tho, perhaps it'd not be a silly idea to do centres last or something?

Also order of steps and the steps themselves DO make a huge difference...
 
Last edited:
Also order of steps and the steps themselves DO make a huge difference...

I'd be impressed if you could find an order of steps to negate the movegroup problems. The order of steps are in no way the biggest issue here.

Look at ZZRoux or FridrichRoux - there are quadrillions of step configurations that all basically amount to the same quality of system.
 
Oh of course it's not the biggest issue. Nor does it 'hardly make any difference'. Don't get me wrong, all I'm saying is it does make a significant difference.

As for thinking up a way to reorder, I can probably think of a different example where it does matter. Just here the move group is quite a big problem and is awkward no matter where you put it. Or why not just not do it...? We could do something else maybe that's easier...

Edit: why not build 1x1x3 blocks then CLL then solve remaining columns? I find that faster and I did that in my 20sub20 vid. This is an example of re ordering which may be helpful
 
Last edited:
Regardless of its practicality, I would like to see someone dedicate a couple years with it and see how far they get.

Maybe a couple years, maybe not, but I'm definitely going to practice it, and possibly switch from Roux to this (or even get to the point of doing CFOP/Roux/Columns first depending on the scramble)
 
Back
Top