The New Method / Substep / Concept Idea Thread

[ShyGuy1265]

If you were to implement phasing, you'd get ZZLL and have probably one of the most feasible techniques for 1LLL using CFOP! You'd probably want to reduce it to only possibilities of disorientation, as your algcount drops to 90 as oppossed to 198

Why not oriented? Are the algs more efficient?

 

[Neuro]

Why not oriented? Are the algs more efficient?

I don't know about the efficiency, but oriented gives you 108 algs as opposed to misoriented which gives 90. This is due to reduced cases when the corner is in the slot (extreme rotational symmetry)

 

[TDM]

Here's a simple idea: ZZ with intuitive LSLL

The idea is to solve the edges <R,U>, then the corners <R,U,D>. Here are some example solves:

43 STM (lucky)
59 STM (unlucky)
50 STM (expected)
49 STM (expected)

Or you could just use petrus Heise

 

[Shiv3r]

Here's a simple idea: ZZ with intuitive LSLL

The idea is to solve the edges <R,U>, then the corners <R,U,D>. Here are some example solves:

43 STM (lucky)
59 STM (unlucky)
50 STM (expected)
49 STM (expected)

ZZ-Heise. Lel I may start using this for the heck of it.

 

[Teoidus]

Or you could just use petrus Heise

haha yeah, that is where I got the idea. Basically all I'm saying is it might be easier to speedsolve with if you break down edge+pairs into solving all the edges, then keyholing in 2 corners.

 

[Shiv3r]

haha yeah, that is where I got the idea. Basically all I'm saying is it might be easier to speedsolve with if you break down edge+pairs into solving all the edges, then keyholing in 2 corners.

so keyholing in 2 corners like how? niklas?
also Ryan talks about this on his page, as the "edges first" approach.

 

[Teoidus]

Keyholing them in with D moves

 

[Neuro]

Alright so I did a preliminary test with 20 out of the 50 solves on my ZZ Variant Stats document. The results were quite interesting. I used the movecount from F2L-1 on every solve using CT, Tri, B, WV, VH, MG, and OLLPLL (OP). I calculated the Mean and SD for each group to see which ones were the "best." Using the top 3 means, I then judged with the SD to see which was the most consistent. This was followed with a thest depicting the dependance of wether the movecount was <=25 depending on the variant.

ZZ-B, ZZ-CT, and ZZ-MG had the best means (in that order.) After viewing the SD's, it showed that ZZ-B was the winner. However, ZZ-CT was only ~.1 greater than ZZ-B in both categories. Given the fact that they also had the same proportion of N to Y in accordance to the movecount being <=25, we can conclude that the two variants are practically equal.

Therefore, I believe that the "best" of these 7 variants is ZZ-CT. CT has much better recognition than ZZ-B, giving it a huge speed advantage that easily outshines the minuscule statistical advantage of ZZ-B.

Here's the link to my document at the moment. If there are any mistakes that I made or any more tests that I should perform, please comment on the document and let me know. Thanks!

 

[Teoidus]

It looks like your mean for ZZ-b is 23.65, which is greater than your mean for ZZ-CT (23.60)? Yet your plots seem to show a different mean for ZZ-b... confused.

Also, I'm don't think I'd agree about recognition being much better with ZZ-CT. ZZ-b recognition is quite straightforward

 

[Teoidus]

39 STM 2GR

z2 // insp
f U M' u r' u' S2 // EOPair 7/7
U R' U F2 // CPLine 4/11
U R M2 u' R2 u' U' M2 // Block 8/19
R' U2 R' U' R2 U R' // F2L 7/26
U R2 F2 R' U2 R' U' R U' R F2 R2 U' // 2GLL 13/39

I'm working on an audio memo scheme that will let one remember EOPair in inspection--I think this might help with making it easier to track CP through EOPair. I can reasonably one-look the whole 2GLine in every ~1/10 or so solves now, but one of the most annoying things I've encountered so far is having to audio memo things like "Fw2 U Fw' R2 Fw" (11 whole syllables just for 5 moves!). In this new scheme, you could simply memo as "kidw(u)b"--much easier to keep in mind while recognizing and tracking CP.

Currently, the scheme is given as follows:

  var dict = [
  "(U, U', U2, u, u', u2) -> (i, o, a, e, oo, au)",
  "(F, F', F2, f, f', f2) -> (f, g, h, b, d, k)",
  "(R, R', R2, r, r', r2) -> (r, v, w, l, p, t)",
  "(M, M', M2, E, E', E2, S, S', S2) -> (n, m, j, ee, ye, ge, s, z, sh)"];

The idea was to optimize the sounds used to represent each turn type in a way that yields an efficient audio code. For example, the hope is that sounds from the R move group (mostly consonants) will mesh well with turn types that are frequently used alongside it in solves (in this case, U moves are vowels, which works nicely, and F moves are (mostly) non-aspirated consonants, increasing chances of forming friendly pairs).

At optimal efficiency, this scheme encodes 2 STM / syllable, which is pretty nice.

Here's the above soln transcribed using this memo scheme:
z2 // insp
bimepoosh // EOPair 7/7
ivih(u) // CPLine 4/11
irjoowoo-oj // Block 8/19
vavowiv // F2L 7/26
iw(u)h(u)vavororh(u)wo // 2GLL 13/39

The extra u's (pronounced "uh") are used to pad awkward letter combos + make silent consonants audible (these are inefficiencies). In this case the scheme has efficiency 39 STM / 21 syllables = 1.85 STM / syllable.

If we compare to just reading the moves out loud (R U f2 R -> "ar yu ef too ar"): 39 STM / 73 syllables = 0.53 STM / syllable.

 

[Neuro]

It looks like your mean for ZZ-b is 23.65, which is greater than your mean for ZZ-CT (23.60)? Yet your plots seem to show a different mean for ZZ-b... confused.

Also, I'm don't think I'd agree about recognition being much better with ZZ-CT. ZZ-b recognition is quite straightforward

Hmm that's weird. I'll check my code but I have no idea how that happened. Also, are 50 solves truly necessary or does 20 per group (7 groups) meet conditions of ANOVA?

I personally think that the recognition for ZZCT is better than ZZB because you already need to track or identify 2 opposite edges during LS and the LL recog can take quite some time to get used to. CT basically mimics the recog of OLL and PLL, which most people are familiar with. They can be equally fast though, just depends on preference I suppose.

 

[Shiv3r]

(5x5 Idea, sorry for breaking up your conversation about ZZ-b)
for Yau5 I came up with a "half"-centers approach to L4C that is similar to what maps600 does, or what Justin thomas does for 6x6/7x7. They do it in three steps(bar, middle bar, finish), and for me it's a little easier. of all the L4C approaches I have used(including center-by-center) this one seems the fastest to me. The Idea is you solve 3 2x3 blocks of center pieces one at a time, then with the fully unsolved center and the completely free slice solve the rest. I am not sure if it is actually that much better than anything else out there, or if someone came up with something similar, but I really like it.

Any Ideas/critiques? I think it could possibly the fastest way to do L4C on Yau5/Meyer5, because in my experience it is much faster.

 

[Teoidus]

Hmm that's weird. I'll check my code but I have no idea how that happened. Also, are 50 solves truly necessary or does 20 per group (7 groups) meet conditions of ANOVA?

I'm not sure; I don't know too much about ANOVAs other than the fact that they're a generalized form of t-test. I would guess that 20 is a bit small given that for a simple t-test you usually want >40 so you can assume normality.

 

[GreyAerin]

I was doing some regular old solving when I thought to myself "Hey What if I make a ZZ-CFOP hybrid method and get really good at it?" Well I was just asking if anyone else had thought of this and would be willing to collaborate with me on this.

 

[JustinTimeCuber]

Some people have had an idea like EOCross/F2L/ZBLL as a method but EOCross is a lot to see during inspection and it's way more efficient to do blockbuilding if you already have the edges oriented.

 

[AlphaSheep]

If the objective is to get an easier last layer, then CFOP with edge control is better. The biggest advantage of doing EO first is that it makes it easier to block build F2L.

 

[FJT97]

The ultimate zzcfop mix is zztop

 

[AlphaSheep]

Alright so I did a preliminary test with 20 out of the 50 solves on my ZZ Variant Stats document. The results were quite interesting. I used the movecount from F2L-1 on every solve using CT, Tri, B, WV, VH, MG, and OLLPLL (OP). I calculated the Mean and SD for each group to see which ones were the "best." Using the top 3 means, I then judged with the SD to see which was the most consistent. This was followed with a thest depicting the dependance of wether the movecount was <=25 depending on the variant.

ZZ-B, ZZ-CT, and ZZ-MG had the best means (in that order.) After viewing the SD's, it showed that ZZ-B was the winner. However, ZZ-CT was only ~.1 greater than ZZ-B in both categories. Given the fact that they also had the same proportion of N to Y in accordance to the movecount being <=25, we can conclude that the two variants are practically equal.

Therefore, I believe that the "best" of these 7 variants is ZZ-CT. CT has much better recognition than ZZ-B, giving it a huge speed advantage that easily outshines the minuscule statistical advantage of ZZ-B.

Here's the link to my document at the moment. If there are any mistakes that I made or any more tests that I should perform, please comment on the document and let me know. Thanks!

Instead of doing 50 samples, it would probably be less effort to work out the exact mean and SDs of move counts for each method. It would eliminate any uncertainty from having a limited sample size.

 

[Mastermind2368]

Sure dude, I'll help. I think I could be useful because I have experience with ZZ and CFOP.

 

[GenTheSnail]

When I first switched from CFOP to ZZ, I was doing a lot of EOCross, because I found block building hard. After my second comp, I was able to transition to full ZZ, and I can confidently say that either CFOP or ZZ is much better than a mix of both.