ZZ-CT Thread

[GenTheSnail]

This might sound stupid but does the orientation of the edge matter during TSLE?

Yes.
The edge in TSLE must always be oriented.
However, because the first step of ZZ, the method used in conjunction with ZZ-CT, orients all edges, you don't need to worry about it.

 

[ExultantCarn]

Yes.
The edge in TSLE must always be oriented.
However, because the first step of ZZ, the method used in conjunction with ZZ-CT, orients all edges, you don't need to worry about it.

What if you decide to insert the edge in the back right slot?

 

[Teoidus]

The algs must be mirrored across the S slice. You can't really rotate because as you say the edge would then be oriented badly

basically just look at the alg e.g. R U R' U R U2 R'

For each move, just do the inverse of it, so do R' U' R U' R' U2 R

 

[lillod]

Let's start the zz-ct vs. cfop argument up again. For the sake of argument let's say that tsle=oll and ttll=pll in recognition and execution time. Now we have zz f2l-1 vs cfop f2l. Is there a clear winner in this ?

 

[ExultantCarn]

ZZ F2L-1 would be faster because you're blockbuilding and you don't have to insert one slot

 

[ExultantCarn]

Could you apply ZZ-CT to CFOP, BUT instead of the TSLE, you use VLS? Also, would you need vls from both the left and right angles or could you just use one

 

[4Chan]

What if you decide to insert the edge in the back right slot?

Slot neutrality is possible if you practice it.

It's fun to do slowly, and you can ADF for the last step.

 

[Cale S]

Could you apply ZZ-CT to CFOP, BUT instead of the TSLE, you use VLS? Also, would you need vls from both the left and right angles or could you just use one

You would need about 6 times as many algs as VLS for CFOP TSLE

This is because with VLS, you have one corner always oriented in a specific direction and an edge oriented

 

[CubingGenius]

Could you apply ZZ-CT to CFOP, BUT instead of the TSLE, you use VLS? Also, would you need vls from both the left and right angles or could you just use one

You would have to use two different angles because of the two different orientations of the edge, which would come to 432 cases. However, you would have to make one corner oriented in a specific way to be able to use VLS which would make it quite impractical for speedsolving.

For 432 + 72(TTLL) = 504 cases, you could learn fast ZBLL subsets, learn fast ZBLS cases and fast OLS cases, which would probably be more practical for CFOP than ZZ-CT.

 

[Teoidus]

Let's start the zz-ct vs. cfop argument up again. For the sake of argument let's say that tsle=oll and ttll=pll in recognition and execution time. Now we have zz f2l-1 vs cfop f2l. Is there a clear winner in this ?

I don't think so, CFOP is more qtm optimized and there's greater potential for xcrosses and CN, while ZZ is more htm optimized and has greater potential for lucky blocks. CFOP has y/y', ZZ has regrips and L2/R2. Also have to take into consideration that "cfop users" won't actually use oll/pll every time, so it's a bit of an iffy comparison

 

[JTcuber]

I don't think so, CFOP is more qtm optimized and there's greater potential for xcrosses and CN, while ZZ is more htm optimized and has greater potential for lucky blocks. CFOP has y/y', ZZ has regrips and L2/R2. Also have to take into consideration that "cfop users" won't actually use oll/pll every time, so it's a bit of an iffy comparison

I would say that for ZZ F2L vs. CFOP F2L, ZZ is a definite winner. You aren't bound by the extra cross pieces, so you don't have to make moves that just fix the cross. Also, You said ZZ has "L2/R2 and regrips". Since when does CFOP not have any regrips?!

 

[Teoidus]

I would say that for ZZ F2L vs. CFOP F2L, ZZ is a definite winner. You aren't bound by the extra cross pieces, so you don't have to make moves that just fix the cross.

I believe analysis of movecounts in ZZF2L vs CFOP F2L show that they have comparable qtm, so I am not sure the efficiency gains given by ZZF2L are as much as you say. (QTM here because I think in this situation it's the best measure of how fast the F2L can be. I will also take insertions like R U' R' over R U R any day).

Also, You said ZZ has "L2/R2 and regrips". Since when does CFOP not have any regrips?!

From what I've seen of CFOP reconstrutions, it's got rotations (aka regrips i guess but i mentioned rotations), then regripless tps spam per pair. Maybe 1 rotation in the middle of a pair, but again, that's rotations. Sure, CFOP sometimes switches between L and R but never in the way that ZZ will. L2/R2 as well still can't really be ignored; these are what make htm efficiency less relevant here, basically forcing regrips and disrupting flow

 

[mDiPalma]

if you don't like the L/R regrips, you have 2 options:

-solve eoline on the left
-just use petrus

 

[JTcuber]

I believe analysis of movecounts in ZZF2L vs CFOP F2L show that they have comparable qtm, so I am not sure the efficiency gains given by ZZF2L are as much as you say. (QTM here because I think in this situation it's the best measure of how fast the F2L can be. I will also take insertions like R U' R' over R U R any day).



From what I've seen of CFOP reconstrutions, it's got rotations (aka regrips i guess but i mentioned rotations), then regripless tps spam per pair. Maybe 1 rotation in the middle of a pair, but again, that's rotations. Sure, CFOP sometimes switches between L and R but never in the way that ZZ will. L2/R2 as well still can't really be ignored; these are what make htm efficiency less relevant here, basically forcing regrips and disrupting flow

I agree, but I tend to get very few L2/R2s in my solves, and there are also very few regrips compared to CFOP. While I do think I tend to slightly prioritize ergonimics over perfect efficiency, I do think that ZZF2L can flow at least as well as CFOP (and I think it flows better because there are no rotations), and the F2L is slightly more efficient, albeit by maybe only 5-7 moves.

 

[Teoidus]

Hm, I'm not sure it's 5-7. This was a long time ago but I remember looking at F2L stats on cubesolv.es and not seeing much of a difference between ZZ and CFOP. To me the comparison between the F2Ls has always boiled down to different tradeoffs in terms of ergonomics

 

[mDiPalma]

if the steps to cfop f2l are defined [cross->easiestpair->easiestpair->easiestpair->pair] and the steps to zz f2l are defined as [eoline->easiestsquare1->easiestsquare2->easiestblock1->block2] (doesn't account for openslotting) and optimal solutions are generated for each step.

cfop f2l : 6.5+23=29.5 htm
zz f2l : 6.2+24.4=30.6 htm

but keep in mind that eof2l is a more desirable state than f2l. the mistake that most people make when calculating the CFOP movecounts is they multiply the "average" 6.7 htm pair insertion by 4.

traditional cfop averages 55 htm, while zz-ct averages 52 htm (what a huge advantage for 2.5x as many algs...).

http://www.speedsolving.com/forum/threads/zz-speedcubing-method.5180/page-6#post-69583

 

[Teoidus]

Arguably wouldn't it also be easier to consistently choose the easiest pair for CFOP F2L compared to consistently choosing the easiest block for ZZF2L?

 

[alwin5b]

Hi

I found about 50 TSLE algs which I like more than the ones from gyroninja/Chris Tran/Blake Thompson (and one OCLL alg that works for ZZ-CT but not for CFOP). All of my algs are shorter or of equal length (in ftm or qtm metric) and I think they are faster to execute.
Here are all the OCLL/PLL/TSLE that I use:

https://docs.google.com/document/d/1FeTnqZJLmA3CLEUby84CJIzdgO67rwuOle5eJJfYhhU/pub

I will also probably try to find better TTLL algs, but Cube Explorer is not really fast enough for that, because the algs are longer. Is Acube better to generate longer algs or which program should I use?

anyway, I hope you find some of my algs useful

 

[JTcuber]

Hi

I found about 50 TSLE algs which I like more than the ones from gyroninja/Chris Tran/Blake Thompson (and one OCLL alg that works for ZZ-CT but not for CFOP). All of my algs are shorter or of equal length (in ftm or qtm metric) and I think they are faster to execute.
Here are all the OCLL/PLL/TSLE that I use:

https://docs.google.com/document/d/1FeTnqZJLmA3CLEUby84CJIzdgO67rwuOle5eJJfYhhU/pub

I will also probably try to find better TTLL algs, but Cube Explorer is not really fast enough for that, because the algs are longer. Is Acube better to generate longer algs or which program should I use?

anyway, I hope you find some of my algs useful

Well, I think these algs are really good, and some are a bit faster than gyroninja's(especially the headlights OCLL case), but I think a big appeal of Chris's algs aren't that they're necessrily the most efficient, but that they're 2 gen, which makes them all insanely ergonomic.

 

[AlphaSheep]

I will also probably try to find better TTLL algs, but Cube Explorer is not really fast enough for that, because the algs are longer. Is Acube better to generate longer algs or which program should I use?

Cube Explorer is heavily optimised compared to the other programs like Acube or Ksolve, so it is unfortunately the fastest. The problem is that the number of possible algs to search through gets very huge very quickly, and that's the nature of the cube, not a shortcoming of any particular program.

If you're not already doing so, limit the moves you search. I generate algs in <RUF> <RUD> and <RUL> first, then generate <RUFD>, and <RUDL> <RUFB> algs (these algs are often nice with rotations/wide moves added in). I can usually generate algs in all of these sets in about 10-15 minutes. Usually I do something else while I wait like check the previous set while the next one is generating, so it's more than fast enough.