Hi, The only problem is that the 'pure version' algs are much slower than the 'speedsolve version' algs (at least for me).
What I do is this: If three edges are corrected oriented after F2L, I will flip the last edge with a 'speedsolve version' alg. And then use I COLL (except for the S and As orientation), so that I will often have a one-look LL after this. If I have a two-look LL, then I have bad luck. Of course I also use COLL if four edges are corrected oriented after F2L. Michael Fung --- In [email protected], "olivsub20" <[EMAIL PROTECTED]> wrote: > > Hi everyone, > to fix the parity I use a method I'm sure you know but I'd like to > remember it to you because in any cases you only have to do one parity > alg. > > When I've solved the F2L I look if there is a Oll parity or not. > 1°) If not you do the OLL and then PLL (with sometimes the PLL parity) > > 2°) If there is a OLL parity problem, you do an OLL so that only one > edge remains flipped(you can choose the OLL between several of them, > and choose the shortest one). Then you can easily see if there is also > a PLL parity or not, and you do the OLL parity alg or the both parity > alg depending on the situation. > > So you have zero or one alg to do. I use this method (like Yuki) since > a long time and it wokrs pretty well. You've almost no break after > little practice. And it seems easier than learning COLL or something else. > > What do you think of that? > > Olivier > > > > > --- In [email protected], "Craig Bouchard" > <logitewty@> wrote: > > > > YES... > > > > HEHE...I couldn't apply this but maybe: > > > > Have an alg for the OLL parity, and have an alg for the OLL parity > > when it is 3 edges...and then do a COLL case to solve the corners, and > > leave the edges to be permuted...The way I do my LL is 4LLL, so I've > > never gotten one of the corner PLL parities...i'm kinda happy about > > that...not sure which is faster...cuz if you do: 1 alg for edges > > (1,2,3,4) then COLL, then PLL edges (then fix PLL parity if needed) I > > think that would be quite fast... > > > > Craig > > > > --- In [email protected], cmhardw <no_reply@> > > wrote: > > > > > > Hey everyone, > > > > > > I have a new LL strategy for centers first people to propose and > > > analyze in this post. I am trying to come up with new ways to handle > > > the parities on a 4x4, and am requesting we put our brains to this > task. > > > > > > Here is the idea, to only have the double parity (meaning do an alg to > > > fix the orientation parity, then do an alg later in the solve to fix > > > the permutation parity) 1/8 the time instead of 1/4. To do this break > > > the orientation parity cases into 2 groups. > > > > > > 1 oriented LL edge: > > > Do either the parity alg or double parity alg leaving a 50-50 chance > > > to also have PLL parity so to encounter double parity here is a 1/8 > > > chance overall. > > > > > > 3 oriented LL edges: > > > Do a COLL alg, now recognizing whether the 3x3 edge groups have the > > > same parity as the corners is very easy. So if you have double parity > > > do the double parity fix pure version, if not do the regular parity > > > fix pure version. > > > > > > So that means only 1/8 the time you do 2 algs. Now don't get excited > > > yet, this method stinks. > > > > > > Here are the times for each LL strategy (for me). I did an average of > > > each alg. > > > > > > permutation parity fix: > > > 02.34, 02.24, 02.63, (03.28), 02.44, 02.73, 02.68, 02.23, 02.43, > > > 02.90, 02.79, (02.11) = 2.54 average > > > > > > orientation parity (speedsolve version - double parity alg): > > > 04.94, 04.47, 05.34, 04.91, 04.65, 05.03, 04.42, 04.45, (04.18), > > > (05.52), 04.97, 05.29 = 4.85 average > > > > > > double parity alg pure version: > > > 06.23, 07.56, (06.02), 08.10, 06.50, (08.24), 08.02, 06.71, 07.64, > > > 07.33, 06.42, 06.24 = 7.07 average > > > > > > orientation-parity-only alg pure version > > > 06.06, (05.98), 06.79, 06.75, 06.77, 06.38, (08.66), 06.51, 06.41, > > > 06.66, 07.40, 07.60 = 6.73 average > > > > > > So here is the analysis of the extra time spent on average just fixing > > > parities: > > > > > > Conventional method with 1/4 double parity: > > > > > > 0.25*0 + 0.25*2.54 + 0.25*4.85 + 0.25*(2.54+4.85) = 3.70 seconds on > > > average to fix parities. > > > > > > ----- > > > > > > and with the new 1/8 double parity method > > > > > > 0.25*0 + 0.25*2.54 + 0.125*(4.85+2.54) + 0.125*(4.85) + 0.125* (7.07) + > > > 0.125*(6.73) = 3.89 seconds on average spent fixing parities. > > > > > > Also solving with the new way I have to do COLL vs. OLL 1/8 the time > > > which is probably 1 second longer. So 1/8 second overall. Making the > > > 3.89 actually 4.02 seconds. > > > > > > In order to make this faster than the conventional approach I would > > > need to solve the pure version double parity alg (x) and the pure > > > version orientation-parity-only alg (y) in: > > > > > > 3.70 = 0.25*0 + 0.25*2.54 + 0.125*(4.85+2.54) + 0.125*(4.85) + > > > 0.125*(x) + 0.125*(y) + 0.125 > > > > > > 2.94 = 0.125*(12.24 + x + y) > > > > > > 11.28 seconds = x + y > > > > > > Which means the sum of both pure alg versions has to be 11.28 seconds > > > or less. > > > > > > We can assume that x can be no faster than 4.85 and y can be no faster > > > than 5.55 which is my average for the speed solve > > > orientation-parity-only alg (again this analysis is done with my > > > times, since those are the only available to me right now). > > > > > > 05.82, 05.38, 05.11, 05.82, 05.54, 05.58, (04.75), (06.07), 05.57, > > > 05.52, 05.74, 05.39 = 5.55 seconds > > > > > > So that means there is only a give room of about 0.8 or 0.4 seconds > > > per alg. Meaning that my pure version double parity alg can only be > > > 0.4 slower than my speed solve version and same for the > > > orientation-only-parity algs. I don't think that's possible for me. > > > So in conclusion again, this method stinks. > > > > > > But can we somehow reduce the 1/4 chance to do both parities and, for > > > me, take 7.39 doing nothing but fixing parities. I mean come on that > > > amount of time is ridiculous. Added on to a solve that would > > > otherwise have been 55 seconds means that 11.91% of the solve is > > > fixing parities. Fixing parities. That's ridiculous, we shouldn't > > > have the standard accept that as ok. > > > > > > Can we take anything from this and form a different, better strategy? > > > Any ideas? My only idea so far is to use the COLL case when you have > > > orientation parity to guess the corner permutation and then compare it > > > to the edge permutation. I think that is fairly thought intensive > > > though, so the amount of decision time required could actually make > > > that strategy take more time fixing parities on average. Alright, > > > well I'm trying to think of something new, anyone else have ideas? > > > > > > Also, should the centers first method be scrapped entirely in favor of > > > a cage method? That would allow me flexibility to fix the orientation > > > parity (the only one!) and also commutators are very easy to come up > > > with on the fly once you have practice and experience with them. So > > > with mastery it seems to me that maybe a cage method is a better > > > choice in the long run than a centers first method. > > > > > > Fixing parity sucks, but the fact that the edge permutation is > > > completely independent of the rest of the cube (!) is what makes the > > > 4x4 so cool in my opinion :-D > > > > > > Chris > > > > > > P.S. If you actually made it to the end of this post congratulations. > > > I know it's long, but I want to come up with a better way to handle > > > the 4x4 parities. Even if it only saves 0.5 second on average, that's > > > still time saved. Thanks for your time spent reading. > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/speedsolvingrubikscube/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
