How about
L U L' B' D2 U R' F2 B' D' U B' R2 U' D' F R D' F' U R B2 D B' D'
--- In speedsolvingrubikscube@yahoogroups.com, "Stefan Pochmann"
<pochmann@...> wrote:
>
> --- In speedsolvingrubikscube@yahoogroups.com, stochastic_antishift
> <no_reply@> wrote:
> >
> > What would the longer algorithms be for the edge cases BU, FU, BD,
> > etc?
>
> Basically of course the same effect, only the piece at DF before the
> alg and the piece at DF after the alg need an extra flip. You can see
> some possible algs in Erik's tutorial:
>
> http://erikku.er.funpic.org/rubik/M2.html
>
> > so for edge cycles, we need a swapping alg for every NEW cycle to
> get
> > some new cycle-starter into the DF spot?
>
> Yes. And preferably break into the new cycle at UB, UF or DB, which
> have the fastest algs. That actually saves time twice, as at the end
> of the cycle you'll close it with the same fast alg. Unless the cycle
> contains an overall flip and you insist on solving BU/FU/BD with
> correct orientation right away.
>
> If you want to do that, you could use Joel van Noort's idea: break
> into a cycle right where one of the pieces UB/UF/DB is located, so
> the next alg *after* breaking into the cycle is fast and avoids the
> lengthy flipping M-slice alg.
>
> > what happens in the case of parity?
>
> After "solving" edges and corners, apply the parity alg:
> (r2' U' r2) (R' U) (L' U2') (R U' R' U2 R) (L U') (r2' U)
>
> > also, for the "unsolved edge orientation" cases you refer
> to,
> > do these only refer to pieces correctly permuted but not oriented
> from
> > the getgo?
>
> Basically, yes. But also possibly some M-slice edges which I've
> "solved" with the wrong orientation. I very much like the case where
> one L or R slice edge was flipped from the getgo, and I saved time
> with M-slice algs leaving three M-slice edges flipped. Then with
> trivial setup, (M'U)*4 does the whole orientation (this btw is the
> case I prefer to point out when trying to explain why flipped M-slice
> edges isn't that bad at all).
>
> Cheers!
> Stefan
>