[Help Thread] ZZ and ZB Discussion

Alright, I'm legitimately sorry for the epic bump, but I don't think any mods will mind.

So, I've approached a couple of people via PM about this subject, but I was thinking "why not just post in the home thread" because there are probably going to be some people who I didn't talk to personally who have a take on the subject.

anyway, so because I've been gathering some thoughts for a ZZ tips tricks etc. thread, the idea of color neutrality again came to mind. Anyone who uses ZZ regularly and thinks about it for a moment will probably agree with me that there are two types of color neutrality that will be viable.

For the sake of discussion, let's imagine that a theoretical ZZ user has a fixed orientation of white on bottom and blue on front. He wants to introduce some color neutrality into his solves, because of course EOline can be a pain when you get especially bad cases.

The way I see it, he has two options. The first one, which I see as being less useful but easier to pull off, is not discriminating between making white and yellow lines. In other words, having z2 neutrality. This is just the ZZ equivalent of opposite color neutrality for Fridrich- he can make a yellow EOline or a white EOline, but would always keep a blue front. The benefits are obvious, and very similar to Fridrich- you can choose between two options, so most of the time you're bound to have a slightly lower movecount / more fingertrick-friendly EOline. Plus, EO detection will be exactly the same, so it really would only be a matter of getting used to looking ahead with yellow pieces instead of white.

His second option, which I perceive as being much more powerful but also much more difficult to incorporate into his solves, would be having total neutrality along the y-axis. Before I go further into this, though, let me explain something about this. We have this theoretical person who uses blue on front, white on bottom, right? There's really nothing stopping him from immediately switching to green on front and white on bottom. The line will be the same, the EO detection will be the same, and the solves will essentially be the same. Having blue on front is basically the same as having green in front, and having red in front is basically the same as having orange in front. This means that when I talk about "neutrality along the y-axis", what I'm really saying is being able to switch between blue and red, because blue is equivalent to green and red is equivalent to orange, so there's no point in learning all four. Only two are necessary.

anyway, as I was saying, being able to switch between a red-in-front orientation and blue-in-front orientation would be hugely helpful. During inspection, you could rotate the the cube to avoid bad EO cases, which would be awesomesauce. Because seriously, EOline is, at least for me, the least consistent and overall slowest step in ZZ. Switching between blue and red would make it so much easier to have fast, low-movecount EOlines. The problem is, it's really hard. I've never made a concerted effort to learn either, but I would imagine that even introducing this tiny bit of freedom into a ZZ solve's orientation would be much harder than a Fridrich user becoming completely color-neutral. Still, it seems viable.

All other types of color neutrality seem, to me, not viable in terms of work : reward ratios. These two types seem the most efficient, time investment wise. You could potentially use both of them, so that you could choose both which EO orientation you work from and which line you make. Again, I have no experience with it in real life, but I imagine that this would drive up the difficulty exponentially.

So, sorry for the wall of text, but here's my question, or series of questions. First, does anyone see any flaws in my reasoning? Anyone disagree?

Has anyone ever experimented with ZZ color neutrality? Does anyone have any other alternative types of color neutrality that I might have overlooked?
And, obviously, I would love to know what people's general opinions are on ZZ color neutrality.

Sorry again for the epic bump!
 
Seems like a good idea. I have recently picked up ZZ and im finding it really hard to do he EOLine in the 15 secs inspection, color neutrality would definitely help, will try it later.
 
Don't be sorry about the bump!
This is is exactly what "insert something" home threads are for: to group relevant info.

I use opposite color neutrality when playing with ZZ.
Yellow or White line with either Blue or Green in front.

But to be honest I do not ZZ speedsolve, I only use it in casual solving so I do not pay any attention to (inspection) times>
 
Yeah, I've played around with switching between blue/green and red/orange. I decided not to pursue it because of inspection time. As it stands, I'm rarely able to plan the entire EOLine in under 15 secs anyway. Maybe I'd have a chance if a y-turn just swapped oriented with unoriented edges, but that's not how it works. I would have to locate them two separate times. (Obviously there is a pattern, it's just too much for me to keep track of.) Further, I can usually handle up to 8 bad edges without a problem, and 10 or 12 doesn't come up that often. So I concluded it is not a great return on investment.

EDIT: Just read that 99.7% of the time EOLine can be done in 7 moves or less. This is a complete guess, but I don't think even fully color neutrality would save you more the 2 moves on average. Anyone want to do the math? Personally, I'm going to work on identifying optimal EOLine in the 15 sec inspection, then I'll decide it cn still makes sense.
 
Last edited:
Yeah, I've read that statistic too, but there are two things that pop into my mind:
First of all, does that statistic apply to solvers who have one fixed orientation? Because I know that I suck at EOLine compared to everything else in ZZ, but I get 9 move EOlines pretty much every time. T.T
Second of all, even if the stat really does apply to fixed-orientation solvers, then switching orientations wouldn't be used to reduce movecount, most of the time. It would be used to remove those fugly EO cases that come along every so often, that take like ten thousand billion seconds to solve.

And finally, I think that the thing about blue/red neutrality is that you need to learn those patterns. In fact, after a little experimentation, I've found that these patterns are fairly easy to memorize, and are actually pretty similar to the rest of ZZ's EO rules. Still, it would be really hard to use effectively, considering how much I rely on my intuition to know where each block goes.
 
Yeah, I would say it's worth it. Here's a complete set of rules:
So, let's assume we have a solver who always has blue on F, white on D.

Their blue/red color neutrality procedure would look like this:

1) Detect EO with blue on front using ruleset (A)
2) Detect EO with red on front using ruleset (B)
3) Choose better case and begin solving.

Here are the rulesets:

Ruleset A is the one we're all familiar with:
1. If U/D shows up on U/D or the F/B sides of the E-slice, it's oriented.
2. If L/R shows up on U/D or the F/B sides of the E-slice, it's misoriented.
3. If F/B shows up on U/D or the F/B sides of the E-slice, then you must check the side of the edge. If U/D shows up on the side of the edge, it's misoriented.

Our theoretical solver would apply these rules the way (s)he always does. Then, instead of performing a y rotation and doing it all over again, he can just apply these similar rules (Ruleset B):

1. A y rotation will never change the orientation of a U/D edge found in the U/D layers.
2. A y rotation will never change the orientation of an E-slice edge found in the E-slice.
3. A y rotation will flip the orientation of a U/D edge found in the E-slice.
4. A y rotation will flip the orientation of an E-slice edge found in the U/D layers.
 
Last edited:
Anonymous said:
Ruleset A is the one we're all familiar with:
1. If U/D shows up on U/D or F/B, it's oriented.
2. If L/R shows up on U/D or F/B, it's misoriented.
Click to expand...

I think the rules are a little different: instead of "or F/B" it should be "or F/B minus M-slice", but ruleset B seems fine to me.

I there a common opinion, who many bad edges are good/easier cases: my preference would be: 0 2 4 8 ...???
 
oll+phase+sync said:
I think the rules are a little different: instead of "or F/B" it should be "or F/B minus M-slice", but ruleset B seems fine to me.

I there a common opinion, who many bad edges are good/easier cases: my preference would be: 0 2 4 8 ...???
Click to expand...

Yes, your corrections are right, and I've edited them in, thanks.
As to your question, it varies a lot on a case-by-case basis. 2, 4, and 8 tend to be the best ones, although 8 can have some pretty nasty cases, and 6 can have some pretty good ones. It's mostly about the placement, rather than the number.
 
haha so last night i thought of a little finger trick for one EO case, just thought i would share ^_^... when you have 8 Miss oriented edges and all your oriented are in the U layer... before i would have just done L2 R2 U F B or some variation of that depending on the line edges. I dont know why i didnt think of this before but its almost easier to do M2 D M2 F B (or X2 before you start and just M2 U F B if you dont mind solving opposite color F2L). of course so much of this is depends on where your Line edges are but just thought i would share
 
Jukuren said:
haha so last night i thought of a little finger trick for one EO case, just thought i would share ^_^... when you have 8 Miss oriented edges and all your oriented are in the U layer... before i would have just done L2 R2 U F B or some variation of that depending on the line edges. I dont know why i didnt think of this before but its almost easier to do M2 D M2 F B (or X2 before you start and just M2 U F B if you dont mind solving opposite color F2L). of course so much of this is depends on where your Line edges are but just thought i would share
Click to expand...

Yeah, a lot of the time I find that using M moves can help with the execution of EO. For instance, when DF, UL, UR, and RB are all misoriented, sometimes I'll just do an x' during inspection, and then perform EO as M' U F. Again, like you said, it depends on the line pieces, but yeah I agree M moves can help a lot.
 
sorry for the bump, but i started learning y axis cn.
do you guys think that after i get the EO when blue is in front i will check which edges stay bad*and* the whole "RED-IN FRONT"EO or just check which edges stay bad and do a Y rotation and check the -red-in-front EO normally?
 
When memorizing bad edges I remember the bad edges per slice (F,S,B)

I tried - and it was rather easy- to remember 2 bad edges states per slice (FU and RU orientation)

But after doing a y turn, I was not able to use this information directly, because my EOLine strategy is bound to always knowing FSB-Slices not LMR-Slices.

But if You use a "global" visualisation system for bad edges it may work for You.
 
You must log in or register to reply here.

Similar threads

iguana
  • Poll Poll
V Perm Discussion Thread
2
Replies
22
Views
236
iguana
iguana
B
CEOR help and discussion thread
Replies
7
Views
635
bcube
B
ikindalikeclock
General Hypercubing Discussion
Replies
1
Views
226
Martyt7777
Martyt7777
Martyt7777
SSL-S5 discussion
Replies
14
Views
924
Martyt7777
Martyt7777
abunickabhi
Speedtyping discussion
Replies
3
Views
257
Martyt7777
Martyt7777
Back
Top