I was alluding to the amount of pieces to be permuted - which is related to the complexity of recognition, especially in this case.
In ZZLL, I believe the case can be identified by looking at only 3 stickers after determining the COLL case (which is second-nature
(1)
"The first point is a high estimate of the amount of moves required to create and insert the last pair while phasing in ZZ-b WITHOUT ANY COMPLICATED ALGORITHMS - simply picking between R U' R' and R U2 R' type inserts. LESS MOVES ARE REQUIRED FOR ZZ-b's PHASING THAN ZZ-CT's TSLE. That is undisputable. I'm not sure what you're trying to say. Look it up."
(2)
"The second point is a comparison of the movecounts of ZZLL and TTLL. There is nothing to argue here either. Having an incorrect corner in the D-layer oriented downwards is inherently NOT a desirable state for efficient algorithms. Insertions of corners into this position and restoring the permutations of the remainder of pieces in the F2L is not an efficient task. It's not even a desirable state for commutator-style finishes. This is a source of the fundamental mathematical disadvantage associated with CT's approach."
(3)
"Next, you can't just deduct algs from a set just because they are 'easy' or you already know them. By the same token logic, you can deduct all the OCLLs/COLLs/PLLS from ZZLL, dropping the alg count by around 40 (or more), depending on the algs you know."
(4)
"You could also argue that ZZLL is only an 80 algorithm set, counting mirrors and inverses. You know how Chris Tran talked about rotational symmetry in his session at Nationals? Yeah, well ZZ-b takes better advantage of that cube-property than ZZ-CT because all the pieces are isolated to the U-layer. Again, this contributes to the mathematical inefficiencies of his approach."
(4)
"Finally, because you've taken a shot at the Petrus method, I will inform you that it is indeed at least 2.4 (+.75 AUF) moves more efficient to solve the cube with Petrus' CP, EP+CO approach (if you combine EP+CO into the relatively small algset known as 2GLL) than to use COLL/EPLL (even look up the inefficient ZZ-orbit set, if you don't believe the statistic), which was not feasible to computationally generate in 1981 when the Petrus method was "invented". Lars Petrus came up with his algs by hand, yet he still managed to identify a cubestate reduction approach superior to the mainstream COLL/EPLL one used today."
(6)
"ZZ was proposed in 2006, which was a far different time in history for the generation of algorithms; therefore it was possible for him to generate all ZZLLs."
(7)
"And if you look at what I said, I didn't say that the methods as they were intended by their creators would be the best. I just said that it would take more than a lousy 2-layer restrictive Orient/Permute style method (which is INHERENTLY INEFFICIENT in both movecount and in cubestate reductions) to beat them out."
(8)
"I still maintain that ZZ-b is the best 2*-look LS/LL ZZ variant, besides, of course, ZZ-a."
(9)
This is the last time I'm going to post on this entire forum to point out the inefficiencies of CT's approach to LS/LL. Quite frankly, it's getting old, and it's not exactly difficult to understand. The method is fine as a 2-look solution to LS/LL, if it's branded as such, but to say that it is superior to ZZ-b by any metric (which is also a 2-look solution to LS/LL) is simply incorrect, mathematically speaking.
(10)
(1)That's like saying ZBLL recognition is easier than PLL because you can get info from the top face. IT WAS DESIGNED TO BE EASY TO RECOGNIZE. Chris Tran made it specifically easy to recognize, because it recognizes like a PLL.
(2)I'm saying that your estimated move count is predicated on saying the F2L pair is already solved, whereas TSLE solves based on the exact opposite. The average move count for optimally solving the last pair in ZZ is 7.5. I'll even give you the benefit of the doubt that phasing adds NO moves to the average movecount(which it does). Even then, TSLE is more efficient. You have the move estimate yourself.
(3)That's a fair enough statement, yet the ergonomics are easily better with TTLL, because one full set is regripless, and 2 are 2-gen. As well, you have a 1/360 chance of skipping the last step in CT, whereas the chances of that happening in ZZLL is admittedly lower than normal ZZ, yet the chances are 1 in thousands, nowhere near the 1 in 360 with CT. The oriented D corner was to create rotational symmetry.
(4)I said that anyone who would seriously learn either of these methods would at least know OCLL and PLL. No one is going from 2 look PLL to CT and ZZLL. COLL is likely, but they aren't guaranteed to know it.
(5)This is idiotic. You obviously know nothing about what rotational symmetry is. Rotational symmetry tells when the corner orientation case is identical in position of the corners with an AUD. With ZZ-CT, this allows for any rotation of the U layer and being the same case. Rotational symmetry is only applicable in ZZLL for the H case, because U2 yields the same corner orientation. Any other case allows for no rotational symmetry whatsoever.
(6)He proposed a 3 step process. That's how he designed it. IT SAYS IT ON HIS WEBSITE. Those 3 are designed to be done separately. The only time he talks about combining steps, is talking about combining CO AND CP! He never alludes to 2GLL in any way.
(7)Yeah, yet Petrus didn't take Petrus past a 3-step system. That was done by others.
(8)ZZ-CT is unarguably the best method for cubestate reduction. Period. It allows for full rotational symmetry, reducing the cases by 1/4, whereas ZZLL allows for half rotational symmetry on one set and none on others.
(9)You realize that this method was created by a ZZ-a user who created it to surpass ZZ-a in ergonomics, alg count, and recognition, right? A ZZ-a user created this specifically to surpass your so-called "best method", and since he has first-hand experience with both, I think he would know.
(10) Your insistence that ZZLL is predicated on the idea that it is more move efficient(it's not), more alg efficient(it's not, because to 2 look LSLL you would need to memorize a case for every F2L phasing case), and more efficient at reducing cubestate(hilariously untrue). But if you don't want to respond to this, I get it. I've thoroughly addressed all your points. I just think it's rediculous that you continue to defend a method that is quantifiably worse based on false knowledge. But I, and anyone else reading this, know you'll probably respond to try to prove me wrong, despite the fact that facts, evidence, and statistics are not just not on your side, but completely against you.
P.S. Sorry for the whole number-parenthesis thing for addrsssing your argument. I'm fairly new to the forum, and I haven't quite figured out the interface. Either way, no hard feelings(it is just cubing after all).
.
