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 <[EMAIL PROTECTED]> 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/
