--- In [email protected], "Gilles Roux" <[EMAIL PROTECTED]> wrote: > > I wrote that some of them only are interesting. Case 3a for example, it would stupid to start a 7 moves orientation sequence (including two U2). M' is enough. And the case is rather easy to recognize, with UL and UR on top. > If an "optimization" makes you loose time, just don't use it. > > As I said, sub-4 is possible without these optimizations. > > Wrong, it should be around 14 if you mix 4a+4b and 4b+4c.
My mistake. So far I'm averaging 18-20, but I'm not very efficient yet at mixing steps, and I can't use any of the special cases or the unconstrained centers. Not fast enough for speedsolving, anyway. :) > > > As edge PLL's average 7 moves, our previous step averages 6.5 or so, > > and our first step at 3.5, this gives us around 17 again. This is only my preliminary number, using the actual case counts and blindly applying the algs. I'm sure this can be less if we can find optimizations for it like you did for Step 4. > > Also, there are a number of lucky cases to exploit. There are only 29 > > or so unique cases for when the edges come up correctly oriented after > > placing DB. There are some very fast cases for when edges are > > correctly placed but incorrectly oriented, and learning the ELL algs > > can help out nicely for the 1/10 of cases where the DF edge completes > > itself along with DB. The worst case scenario is 26 moves to finish, > > and comes up roughly 1/2880 cases, while the odds for a 4 move or > > fewer solution are 1/72. I need some assistance finding nice optimizations as you did for Step 4. How did you come up with those? Perhaps a similar process would work well here. I know placing the last 5 edges once oriented should work out to 10 or fewer moves, and the ELL cases work out to around 12 on average, giving those cases fewer than 17 moves on average. But I'm certain there is a way to reduce the moves for the general cases. One good way is to try to orient edges when inserting the DB piece. Scramble with M U M' U2. To insert this with M U M', you leave two incorrect edges for the next step, which is not as nice to fix. Inserting it with the inverse of the scramble now costs you one move, but gives you a nice 3 move insertion for the second step, or possibly a finish for the final 5 simultaneously. > I think that EPLL as the last step is not a very good idea, permuting M-edges is much faster. I'm working on it. ;) > ACube is very nice and useful, but it's not the right tool when centers are moving parts. > > Thanks for contributing! > > Gilles. I know it's not very good for this, but it's better than me slowly attempting to find things by hand. If anyone still wants to help me out with this on ACube, I'm very interested. -Mike ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/MXMplB/TM --------------------------------------------------------------------~-> 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/
