Hi friends,

Could Chris/Per/Stefan please explain why they think there cannot be a method 
other than counting cycles?
I would love to see a proof! Or better, I would love to see a proof of a better 
method. :-)

Yesterday I found a counter example of my factor 4 hypothesis: just swap the 
edge cubies UrF and URb. You have 0 flipped edge pieces, but you do have parity.
When I started this solve the total number of flipped edge pieces was 14 
(=parity, which was the indeed the case), so somewhere in the solve it changed 
to a factor of 4.

CLL=>ELL is indeed an interesting approach. :-)

Orientation parity during F2L was an idea I already had, and I asked Jaap to 
find an algorithm for it, using his program. At the moment he is still on tour 
in Florida. :-)

Stefan, I don't understand what you mean with your idea about dedges.

Doing both parities in one is interesting. At the moment I use two algorithms 
(the normal one by Chris, and the double parity one by Frédérick), but both 
twist corners because I use multislice moves. It would be great to have a fast 
algorithm that does not twist corners... It would be great to have a fast 
algorithm for the orientation parity anyhow. Yuki can do the parity algorithm 
amazingly fast. I need to train for that. :-)

Is it true that once you solved 3 centers, you cannot change parity anymore 
when you keep these centers intact? Because then the center positions are fixed?
In that case you only have to count the parity during the first three centers. 
Which is not a big task.

Thanks and have fun,

Ron

----- Original Message ----- 
  From: Stefan Pochmann 
  To: [email protected] 
  Sent: Sunday, November 13, 2005 4:08 AM
  Subject: [Speed cubing group] Re: 4x4x4 parity without counting cycles


  --- In [email protected], "Ron" <[EMAIL PROTECTED]> 
wrote:
  >
  > One of the subjects was avoiding the orientation parity, as already 
  > investigated by Chris Hardwick.
  > I really think there must be an easier way to check this parity, 
  > than to count the cycles. Counting cycles takes quite a lot of time, 
  > because you have to follow all pieces around the cube.

  I don't think there's an easy way out and like Per I don't think it 
  would be worth it anyway unless maybe you can really see it in 5-10 
  seconds.

  Some in my opinion more realistic time-savers dealing with the 
  parities in a centers>edges>3x3 method:

  - Do CLL->ELL, solving both parities as part of ELL. It's an easy 
  2-look LL.

  - Recognize and fix orientation parity before solving the last F2L 
  pair. Chris should already be able to recognize it since he's doing 
  ZBF2L and it's not hard to learn anyway. Now we just need a fast alg 
  that exploits the unsolved slot. Should be shorter/faster than what we 
  have so far.

  - While pairing up dedges, don't flip built dedges anymore (optimally 
  don't change them at all) and count flipped dedges. Then you could fix 
  the parity before starting the 3x3 step. An even shorter/faster alg 
  should exist.

  Cheers!
  Stefan







------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "speedsolvingrubikscube" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     [EMAIL PROTECTED]
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]



------------------------ 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/
 


Reply via email to