Yeah, could we try this scramble, only could we apply an orientation
swap to the DL and DR edges? ie. the scramble R B2 L' R2 D2 F2 R2 F2 R
U2 F U' F2 D' B' D2 U' R' B2 D' F'

--- In speedsolvingrubikscube@yahoogroups.com, "richard16meyer"
<richard16meyer@...> wrote:
>
> 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
> >
>