Help with idea for easier zz-b method

[something_to_remembe]

I have read about the zz method and I thought that maybe for an intermediate -advance solution, that after the phasing you could split the the last step into two steps. It has 167 cases and you need to memorize 80 algorithms for it. Then I read about the petrus method. In the petrus method there is a perfect enough system which is a two algorithm one look, which I think is genius. But it is still a lot to memorize. If after the phasing in the the zz-b method you used a similar method you could probably do it more easily. Memorizing about 20 algorithms. Could anybody help me with algorithms for these cases. On the petrus method, to do this i still need to memorize just about all of them (I stopped checking after 35). About 20 or less would be preferred.

 

[Lord Voldemort]

If you split it into 2 steps, why not just use COLL and EPLL?
(And could you elaborate on the "genius method"? It's confusing what you said)

 

[something_to_remembe]

For your first question, i think that (i'm not sure) this will require memorization of less algorithms and/or be faster. The last two steps are one look. Plus i just like the idea of phasing, i have no idea why.

For your second question here is the link for the last layer to the petrus method i was talking about. I just called it genius because i thought it was really smart.

http://lar5.com/cube/270/index.html

 

[blah]

@LV: Because COLL + EPLL requires two looks. The "genius method" requires one.

@something...: So what help do you need? You've already detailed every step of this variation, it's obviously not a new idea, but I doubt anyone's ever bothered looking for compound-ZZLL algs anyway, so now go look for your algs and publish them to help others, rather than asking for help when you already know exactly what to do. I highly doubt it's just "20 algorithms" though.

 

[Cride5]

If you learn COLL algs which don't mess up edge permutation, then you could use it with EPLL to do a 1-look, 2-alg LL. The recognition would be exactly the same as ZBLL. The downside to this approach is that algs for the COLL stage will be slightly longer on average.

 

[something_to_remembe]

I cant make the algs because i don't have time to make the program that will do it for me (combine them) and doing it myself by hand would take even longer. There are programs to find algs, but i cant find any to combine them. If its not 20 algorithms i just hope it would be less than 30. (Petrus uses 40 without phasing).

I might do what you suggested with COLL without messing up edge permutation.

 

[blah]

If you learn COLL algs which don't mess up edge permutation, then you could use it with EPLL to do a 1-look, 2-alg LL. The recognition would be exactly the same as ZBLL. The downside to this approach is that algs for the COLL stage will be slightly longer on average.

If you learn COLL algs which do mess up edge permutation, then you could use it with EPLL to do a 1-look, 2-alg LL. The recognition would be exactly the same as ZBLL. The upside to this approach is that algs for the COLL stage will be slightly shorter on average.

I cant make the algs because i don't have time to make the program that will do it for me (combine them) and doing it myself by hand would take even longer. There are programs to find algs, but i cant find any to combine them. If its not 20 algorithms i just hope it would be less than 30. (Petrus uses 40 without phasing).

You need to start getting brave enough to get your hands dirty I'm serious, it's not hard as it appears to you. For what it's worth, it doesn't appear hard to me at all, and I believe it shouldn't to you either. Methods and algs don't just appear out of thin air with automated programs

 

[Cride5]

If you learn COLL algs which don't mess up edge permutation, then you could use it with EPLL to do a 1-look, 2-alg LL. The recognition would be exactly the same as ZBLL. The downside to this approach is that algs for the COLL stage will be slightly longer on average.

If you learn COLL algs which do mess up edge permutation, then you could use it with EPLL to do a 1-look, 2-alg LL. The recognition would be exactly the same as ZBLL. The upside to this approach is that algs for the COLL stage will be slightly shorter on average.

Not sure I follow :confused: Are you proposing just using normal COLL algs and memorising how each alg permutes the edges? I'd imagine doing this to anticipate the EPLL would take a fair amount of mental effort! The idea with using a non edge permuting version of COLL would be that the EPLL case is visible at the initial LL inspection.

... or are you just getting at a technicality? Ie. "COLL" by definition doesn't preserve edge permutation. To clarify: I'm proposing a set of algs to orient and permute the LL corners without permuting the edges. This is essentially and enhanced version of COLL. These algs can be found by taking the subset of ZBLL in which edges are not permuted.

 

[blah]

Yeah I knew what you were talking about.

I may be wrong, but I don't see anything wrong with doing what I said. And I don't see how your approach is any better than mine. It's really hard for me to succinctly describe how I'd implement whatever I said, but rest assured, I do have a pretty clear idea of what I'm talking about. Here's the best analogy I could think of right now:

When you get a G perm, would you look at the corners and edges separately to identify which one you've got? No. You look at the entire LL as a whole and look for recognition patterns like blocks and headlights. Get it?

It's not the best analogy but it brings certain points across, I hope.

 

[Lord Voldemort]

No, since you've already recognised what you do. While you don't do that right now, if you consciously try to look at the 2 separate parts, I'm sure it's possible. Another upside would be that you'll be able to continue using these COLLs if you move on to zz-b.

 

[Cride5]

Yeah I knew what you were talking about.

I may be wrong, but I don't see anything wrong with doing what I said. And I don't see how your approach is any better than mine. It's really hard for me to succinctly describe how I'd implement whatever I said, but rest assured, I do have a pretty clear idea of what I'm talking about. Here's the best analogy I could think of right now:

When you get a G perm, would you look at the corners and edges separately to identify which one you've got? No. You look at the entire LL as a whole and look for recognition patterns like blocks and headlights. Get it?

It's not the best analogy but it brings certain points across, I hope.

Surely the move-count advantage of using normal COLL doesn't warrant learning to differentiate between all 494 ZBLL cases!

The advantage with using non-edge permuting COLL is that COLL and EPLL can be inspected independently. The recognition involves selecting between one of 40 cases for COLL, and one of 4 cases for EPLL, giving a total of 44.

Using your approach, for each COLL case you'll need to be able to recognize and remember how each possible edge permutation is affected by the specific COLL alg being used. Even if you're using special recognition techniques, you're still making a selection between one of 494 possible cases.

 

[blah]

Yeah I knew what you were talking about.

I may be wrong, but I don't see anything wrong with doing what I said. And I don't see how your approach is any better than mine. It's really hard for me to succinctly describe how I'd implement whatever I said, but rest assured, I do have a pretty clear idea of what I'm talking about. Here's the best analogy I could think of right now:

When you get a G perm, would you look at the corners and edges separately to identify which one you've got? No. You look at the entire LL as a whole and look for recognition patterns like blocks and headlights. Get it?

It's not the best analogy but it brings certain points across, I hope.

Surely the move-count advantage of using normal COLL doesn't warrant learning to differentiate between all 494 ZBLL cases!

The advantage with using non-edge permuting COLL is that COLL and EPLL can be inspected independently. The recognition involves selecting between one of 40 cases for COLL, and one of 4 cases for EPLL, giving a total of 40 + 4 total.

Using your approach, for each COLL case you'll need to be able to recognize and remember how each possible edge permutation is affected by the specific COLL alg being used. Even if you're using special recognition techniques, you're still making a selection between one of 494 possible cases.

Then with your approach, there really isn't much difference between 1-look and 2-look! In fact, I'd argue that it's easier to recognize the cases with 2-look, so much so that it can actually be faster than 1-look. Think about it, how on earth are you gonna determine whether it's a U or H or Z perm in an extremely short amount of time, just by looking at the positions of the edges relative to each other, without having solved corners as reference points? See the problem now?

The above argument assumes we were talking about ZBLL instead of ZZLL, because you quoted 494.

 

[something_to_remembe]

I could try to start combining algorithms myself, but there are about 160 algorithms for it. To see which to combine i'd need 160*160 and see what they solve, because it could be a double algorithm. Actually i would need 160*160*4 because after the first algorithm i may want to switch angles. I'm in middle school and that kind of work by hand would take years.

 

[Cride5]

Then with your approach, there really isn't much difference between 1-look and 2-look! In fact, I'd argue that it's easier to recognize the cases with 2-look, so much so that it can actually be faster than 1-look. Think about it, how on earth are you gonna determine whether it's a U or H or Z perm in an extremely short amount of time, just by looking at the positions of the edges relative to each other, without having solved corners as reference points? See the problem now?

The above argument assumes we were talking about ZBLL instead of ZZLL, because you quoted 494.

Hmm, interesting observation H perm looks the same as a solved state if you don't have the corners as a reference point. Only looking at the edges you can only narrow it down to

• H or solved
• Z
• Ua or Ub

.. so although you'll have some clue what's coming, you won't be able to pin it down exactly. It could be resolved by choosing a specific corner as a reference point in each COLL case, but this is probably getting too complicated. Guess I'd just stick with regular COLL

 

[blindalchemist]

Do you intend this to be a stepping stone on the way to full ZZLL?

 

[Cride5]

Learning plain COLL is deffo a step in the right direction if you intend on learning ZZLL. As a transition between COLL and ZZLL, I think this idea possibly has more promise than trying to anticipate the EPLL case before COLL. Instead of phasing, edge permutation is solved completely during insertion of the last slot, allowing completion of the LL with COLL algs which don't orient or permute the edges (NOTE: This is exactly the same as the non-parity case after phasing). However as qqwref pointed out, the recognition is probably not all that great, and some of the algs are quite long.

If I were personally in the transition from COLL to ZZLL, I'd be practising phasing, and learning how to recognise non-parity/parity/rotated parity.