ZZ Cubers

[GenTheSnail]

I noticed that no one has posted on this thread for a year and a half now so I thought I might .
I recently switched from CFOP (averaging around 14 secs) to ZZ. I can't help but notice that there still aren't that many world class ZZ users in comparison to the number of CFOP users. Personally, I believe that a method such as ZZ-CT has so much potential. This is why I switched and I think that it should be more recognised. I myself would really like to see how fast people can get with this method . Perhaps any ZZ users or ZZ-CT users could post there averages on here as I am curious as to how fast some people are with it and how many people actually use ZZ-CT or still use ZZ.

It's great that you're interested in ZZ, I love the method and also switched from early CFOP.
However, a thread that is not dead is the ZZ/ZB thread. Also there is a ZZ-CT thread if you are interested. If you have any questions, you should probably post questions there.
I regard to your question: I average high 14 on 3x3, high 20 on 3x3 One Handed, and sub-1ish on 3x3 with Feet. I use ZZ for all of these with mostly an LL of COLL/EPLL. I'm learning the Anti-Sune COLL set, and use a few hand picked ZBLLs.

 

[Thecuberrr]

It's great that you're interested in ZZ, I love the method and also switched from early CFOP.
However, a thread that is not dead is the ZZ/ZB thread. Also there is a ZZ-CT thread if you are interested. If you have any questions, you should probably post questions there.
I regard to your question: I average high 14 on 3x3, high 20 on 3x3 One Handed, and sub-1ish on 3x3 with Feet. I use ZZ for all of these with mostly an LL of COLL/EPLL. I'm learning the Anti-Sune COLL set, and use a few hand picked ZBLLs.

Thanks for the reply and for the tips. How long did it take you to learn COLL?

 

[GenTheSnail]

Thanks for the reply and for the tips. How long did it take you to learn COLL?

I learned H, Pi, T, U, and L sets a couple months ago. I suppose that took around less than two months.
I recently decided to learn S/AS sets, and S set took me a little less than a week, and I'm about halfway done with SA.
It really helps that I know how to recognize the cases, which helps me learn them faster.

 

[Allahjabark]

Could someone explain to me in detail the NMLL method, as I am really interested and want to learn it, but there are so few resources for it. Here is a link so you know what I am talking about.

link:

https://docs.google.com/spreadsheet...09qEFePOzInwvFu99QBXkwddk/edit?hl=en_US#gid=0

 

[CubingGenius]

Could someone explain to me in detail the NMLL method, as I am really interested and want to learn it, but there are so few resources for it. Here is a link so you know what I am talking about.

link:

https://docs.google.com/spreadsheet...09qEFePOzInwvFu99QBXkwddk/edit?hl=en_US#gid=0

Take a look here.

 

[Thecuberrr]

Thanks for the reply and for the tips. How long did it take you to learn COLL?

Thanks again for the quick reply. Out of interest, are you interested in ZZ-CT and what do you think about it. I am considering learning the algs but can't decide on wether I should do it or not.

 

[CubingGenius]

Thanks again for the quick reply. Out of interest, are you interested in ZZ-CT and what do you think about it. I am considering learning the algs but can't decide on wether I should do it or not.

I know COLL and EPLL minus sune and antisune and I also use 2GLL and ZBLL.

I don't think ZZ-CT gives the greatest advantage for a two look LS+LL. If I'd have to choose, I'd prefer ZZ-b over ZZ-CT.

They have a similar algorithm count but the way they are executed are very different. I'd recommend you look at both and some other options here before deciding what to do.

 

[GenTheSnail]

Thanks again for the quick reply. Out of interest, are you interested in ZZ-CT and what do you think about it. I am considering learning the algs but can't decide on wether I should do it or not.

When the method first came out, I got pretty hyped, but after a couple months of not learning algs, I've decided to go for ZBLL instead.
What made me decide to not learn CT was a combination of things, all of which are not necessarily the best reasons.
Mostly, they were:
Several posts in the ZZ-CT Thread 1, 2
If I'm going to learn that many algs, I want it to be worth it. ZZ-a is considered to be the best.
Recognition for 100+ TSLEs suck/I already know how to recognize ZBLLs
Being able to maintain my current speeds/seamless integration into my solves of algs

The last two reasons are basically why I didn't continue with ZZ-CT, though it was a combination of all of them.
I had already learned some ZBLLs through recognizing EPLL skips in my COLLs, and I just decided to go all the way.

If you want to learn ZZ-CT; go ahead! It's still a good method.

 

[Thecuberrr]

When the method first came out, I got pretty hyped, but after a couple months of not learning algs, I've decided to go for ZBLL instead.
What made me decide to not learn CT was a combination of things, all of which are not necessarily the best reasons.
Mostly, they were:
Several posts in the ZZ-CT Thread 1, 2
If I'm going to learn that many algs, I want it to be worth it. ZZ-a is considered to be the best.
Recognition for 100+ TSLEs suck/I already know how to recognize ZBLLs
Being able to maintain my current speeds/seamless integration into my solves of algs

The last two reasons are basically why I didn't continue with ZZ-CT, though it was a combination of all of them.
I had already learned some ZBLLs through recognizing EPLL skips in my COLLs, and I just decided to go all the way.

If you want to learn ZZ-CT; go ahead! It's still a good method.

Thanks again for the reply, I think I probably will do

 

[JTcuber]

I don't think ZZ-CT gives the greatest advantage for a two look LS+LL. If I'd have to choose, I'd prefer ZZ-b over ZZ-CT.

They have a similar algorithm count but the way they are executed are very different. I'd recommend you look at both and some other options here before deciding what to do.

I think CT is better than ZZ-b, because I think the recognition for TTLL is better than ZZLLs, and the algs tend to be waaaaaay more ergonomic. And for ZZ-b to even be about on the same level, you would have to learn the full set for LS, where you have to recognize the ep for 2 edges and the F2L edge and corner permutation. Otherwise you're basically doing 2lls(recognizing edge and corner F2L permutation and then edge permutation) and then the ZZLL, which can be really tough to recognize.

 

[mDiPalma]

I think CT is better than ZZ-b, because I think the recognition for TTLL is better than ZZLLs, and the algs tend to be waaaaaay more ergonomic. And for ZZ-b to even be about on the same level, you would have to learn the full set for LS, where you have to recognize the ep for 2 edges and the F2L edge and corner permutation. Otherwise you're basically doing 2lls(recognizing edge and corner F2L permutation and then edge permutation) and then the ZZLL, which can be really tough to recognize.

Let me ask you, which is less:
a) 6.7+3 <RU>
or b) 10.37 <RU>?

and which is less:
a) 13
or b) 15.21?

and which is less:
a) 8 pieces
or b) 9 pieces?

and which is less:
a) 169 algs
or b) 197 algs?

The conclusion that ZZ-CT is superior to ZZ-b on any quantitative basis requires honestly answering "b" to every question above.

Without any disrespect, ZZ-b was the way ZZ was intended to be executed, by its creator. You're not going to beat the approach out with any old orient/permute based method of a comparable alg count. To use Tony Snyder's terminology, these methods have a "mathematical disadvantage".

 

[CubingGenius]

I think CT is better than ZZ-b, because I think the recognition for TTLL is better than ZZLLs, and the algs tend to be waaaaaay more ergonomic. And for ZZ-b to even be about on the same level, you would have to learn the full set for LS, where you have to recognize the ep for 2 edges and the F2L edge and corner permutation. Otherwise you're basically doing 2lls(recognizing edge and corner F2L permutation and then edge permutation) and then the ZZLL, which can be really tough to recognize.

I can understand where you are coming from about the recognition, but I don't know how you got that TTLL's algs better than ZZLL's.

The recognition for ZZLL also requires orientation recognition, but you could also argue that TTLL requires D layer recognition as well.

The algs for TTLL are definitely not as good as ZZLL. There are lots of awkward algorithms compared to ZZLL where the number is fewer and the algorithms are generally lower movecount.

Phasing vs TSLE is probably a better comparison, I think TSLE might be slightly better in this bit, since they both have a similar move count (I think TSLE is lower) and phasing is a bit more difficult to recognise.

TSLE is a very good step in ZZ-CT, but TTLL is the weaker part and doesn't do as well compared to ZZLL, ZBLL etc.

That's why I'd prefer ZZ-b over ZZ-CT.

 

[GenTheSnail]

and which is less:
a) 8 pieces
or b) 9 pieces?

Okay this is the only thing that you shouldn't have argued.
It's just a bad point, and can be really easily proven wrong and irrelevant.
For example: would you rather solve a Sune (3 pieces, 7 moves) or an L (2 pieces, 8 moves) OCLL case?

I won't participate in this debate, as I don't know much of ZBLL, and none of TTLL.

 

[JTcuber]

I can understand where you are coming from about the recognition, but I don't know how you got that TTLL's algs better than ZZLL's.

The recognition for ZZLL also requires orientation recognition, but you could also argue that TTLL requires D layer recognition as well.

The algs for TTLL are definitely not as good as ZZLL. There are lots of awkward algorithms compared to ZZLL where the number is fewer and the algorithms are generally lower movecount.

Phasing vs TSLE is probably a better comparison, I think TSLE might be slightly better in this bit, since they both have a similar move count (I think TSLE is lower) and phasing is a bit more difficult to recognise.

TSLE is a very good step in ZZ-CT, but TTLL is the weaker part and doesn't do as well compared to ZZLL, ZBLL etc.

That's why I'd prefer ZZ-b over ZZ-CT.

TTLL I think has easily better recognition. It's very similar to PLL, in that you only have to recognize blocks. You never need to look at the D layer. I've looked at the recognition for all the algs, and the worst ones are when there are no blocks, and you look to see if the edge in the side with the headlights is an opposite or adjacent color to the headlights. There really isn't a bad case for recognition, there are just good ones and meh ones. But there's no D recognition. That's why gyroninja only has the U layer in his TTLL page

 

[CubingGenius]

TTLL I think has easily better recognition. It's very similar to PLL, in that you only have to recognize blocks. You never need to look at the D layer. I've looked at the recognition for all the algs, and the worst ones are when there are no blocks, and you look to see if the edge in the side with the headlights is an opposite or adjacent color to the headlights. There really isn't a bad case for recognition, there are just good ones and meh ones. But there's no D recognition. That's why gyroninja only has the U layer in his TTLL page

But in order to do that the F2L corner must be at the ULB location. If it isn't then you have to AUF to recognise which takes longer on the TTLL part.

And what do you mean by blocks? Are you talking about recognising it from 2 sides or not?

 

[JTcuber]

But in order to do that the F2L corner must be at the ULB location. If it isn't then you have to AUF to recognise which takes longer on the TTLL part.

And what do you mean by blocks? Are you talking about recognising it from 2 sides or not?

What? I never said anything about only 2 sides. You position the F2L corner at ULB(you only need to look at the white of it, knowing what other colors it has is irrelevant) and then you have one of 6 sets, either front bar, right bar, all bars, front opp(2-gen), right opp(2-gen), and both opp. You then look at the blocks. Most look like R-perms or G-perms. I would say it's maybe about on the recognition level if you were to learn a PLL for every 4x4 PLL case.(I'm not sure how many cases that would be). But I would say it's harder than PLL. From experience, I found it about as difficult as recognizing COLL

Let me ask you, which is less:
a) 6.7+3 <RU>
or b) 10.37 <RU>?

and which is less:
a) 13
or b) 15.21?

and which is less:
a) 8 pieces
or b) 9 pieces?

and which is less:
a) 169 algs
or b) 197 algs?

The conclusion that ZZ-CT is superior to ZZ-b on any quantitative basis requires honestly answering "b" to every question above.

Without any disrespect, ZZ-b was the way ZZ was intended to be executed, by its creator. You're not going to beat the approach out with any old orient/permute based method of a comparable alg count. To use Tony Snyder's terminology, these methods have a "mathematical disadvantage".

I may be missing something, but I didn't get those first 2 points at all. Second, the solving of those 9 pieces requires less algs than solving those 8. You aren't taking into account the algs you would need to take into account for phasing for it to be at all on the same level as CT, because it does its last slot type step in one look, whereas intuitive phasing does it in 2 looks, where you get a pair and then phase, which would also be a higher move count. The algs for CT are also quantifiably better, one because they are extremely ergonomic, with one set being regripless, and 2 others being 2 gen, along with quite a few algs being 1 move conjugates of PLL. And what does the alg count have to do with anything? One, your number is wrong, because anyone who knows OCLL and PLL(anyone who would switch to either of these methods) would know 28 of the algs! 3 of the TSLEs are just RUR', RU'R, or RU2R', which everyone would also know. So if you want to compare arbitrary alg numbers, you should compare 167 to 169. Even though it is irrelevant, because OCLL and PLL are so many less algs than ZBLL, doesn't make it better. So yeah, your points are irrelevant.

Without any disrespect, ZZ-b was the way ZZ was intended to be executed, by its creator.

Why bring ZZ into this in the first place? Method creators are wrong about method execution all the time. Petrie thought you should do CP, CO, and EP in that order for Petrus. I don't think you're gonna argue that that's better than COLL and EPLL, or ZBLL. Fridrich also only though Fridrich method would be OLL, PLL, yet OLLCP, VLS, and things of the like are easily better

 

[CubingGenius]

What? I never said anything about only 2 sides. You position the F2L corner at ULB(you only need to look at the white of it, knowing what other colors it has is irrelevant) and then you have one of 6 sets, either front bar, right bar, all bars, front opp(2-gen), right opp(2-gen), and both opp. You then look at the blocks. Most look like R-perms or G-perms. I would say it's maybe about on the recognition level if you were to learn a PLL for every 4x4 PLL case.(I'm not sure how many cases that would be). But I would say it's harder than PLL. From experience, I found it about as difficult as recognizing COLL

I think I understand what you mean about the corner permutation. But I don't recognise it as a bar, I recognise it as a same colour relation and opposite colour relation.

By blocks, do you mean you look for things like 1x2x2 blocks? I recognise edge permutation by looking at the FU and RU edge's stickers and compare them with the FRU corner's stickers with same and opposite colour relations to work out the edge permutation.

The reason I mentioned the D layer was that you needed to look at that to recognise the TTLL without AUFing.

 

[JTcuber]

I think I understand what you mean about the corner permutation. But I don't recognise it as a bar, I recognise it as a same colour relation and opposite colour relation.

By blocks, do you mean you look for things like 1x2x2 blocks? I recognise edge permutation by looking at the FU and RU edge's stickers and compare them with the FRU corner's stickers with same and opposite colour relations to work out the edge permutation.

The reason I mentioned the D layer was that you needed to look at that to recognise the TTLL without AUFing.

Yes, you look mostly for 1x2 or 1x3 bars, but on occasion you have to look at the EP of one edge in relation to headlights it's in. You rarely need to look at the EP of more than one edge, except for the all bars case, which recognizes like EPLLS

 

[mDiPalma]

Okay this is the only thing that you shouldn't have argued.
It's just a bad point, and can be really easily proven wrong and irrelevant.

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 4 stickers after determining the COLL case (which is second-nature). The last step of ZZ-CT requires more sticker information to identify. Especially because there are no second-nature clues like corner orientations (in fact almost no information is conveyed by the U-face).

I may be missing something, but I didn't get those first 2 points at all. Second, the solving of those 9 pieces requires less algs than solving those 8. You aren't taking into account the algs you would need to take into account for phasing for it to be at all on the same level as CT, because it does its last slot type step in one look, whereas intuitive phasing does it in 2 looks, where you get a pair and then phase, which would also be a higher move count. The algs for CT are also quantifiably better, one because they are extremely ergonomic, with one set being regripless, and 2 others being 2 gen, along with quite a few algs being 1 move conjugates of PLL. And what does the alg count have to do with anything? One, your number is wrong, because anyone who knows OCLL and PLL(anyone who would switch to either of these methods) would know 28 of the algs! 3 of the TSLEs are just RUR', RU'R, or RU2R', which everyone would also know. So if you want to compare arbitrary alg numbers, you should compare 167 to 169. Even though it is irrelevant, because OCLL and PLL are so many less algs than ZBLL, doesn't make it better. So yeah, your points are irrelevant.

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.

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.

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

Why bring ZZ into this in the first place? Method creators are wrong about method execution all the time. Petrie thought you should do CP, CO, and EP in that order for Petrus. I don't think you're gonna argue that that's better than COLL and EPLL, or ZBLL. Fridrich also only though Fridrich method would be OLL, PLL, yet OLLCP, VLS, and things of the like are easily better

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

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. I still maintain that ZZ-b is the best 2*-look LS/LL ZZ variant, besides, of course, ZZ-a.

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.

 

[JTcuber]

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