• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Old Heise as a Speedsolving Method?

Silky

Member
Joined
Apr 5, 2020
Messages
874
Just curious about ya'll thoughts on Old Heise and whether it is a viable speedsolving method. I am aware of Speed-Heise 1 & 2 but am more curious of Heise's original proposal for a speedsolving variant of Heise. I'm also interested in ya'll thoughts on Old Heise vs to Speed-Heise 1 & 2. Also is there anyone who seriously uses any of these methods ?
 
Joined
Sep 10, 2019
Messages
1,542
Imo, it's not really good, but you can definitely get sub-10 with it if you work a lot. However, if you want something similar but fast, I would recommend Petrus.
 

Silky

Member
Joined
Apr 5, 2020
Messages
874
@WarriorCatCuber @nairismic

I dont think many people use that method. I recommend Roux, ZZ, Petrus and maybe Cfop, but honestly I only use it because I'm too lazy to switch.

Sent from my Walton Refrigerator using Tapatalk

Imo, it's not really good, but you can definitely get sub-10 with it if you work a lot. However, if you want something similar but fast, I would recommend Petrus.

I've experimented with the Big Four a while back; specifically with Roux and Petrus. I switch to Roux in the early 10s for speed solving. I also experimented with Heise but for FMC/novelty/elegance rather than speed. I didn't realize that Heise came out with a variant more tailored to speed solving with the use of L4C ( similar to the Hahn method ).

I more curious at exploring older methods for speed solving similar to @efattah 's reexamination of Corners First methods ( and Waterman ? ).

It says Andy Camann used it in the early 2000s to achieve sub-17 times so I'm kinda just interested in if anyone else has follow up on this method since 2004 and how good it might be.
 
Joined
Sep 10, 2019
Messages
1,542
@WarriorCatCuber @nairismic





I've experimented with the Big Four a while back; specifically with Roux and Petrus. I switch to Roux in the early 10s for speed solving. I also experimented with Heise but for FMC/novelty/elegance rather than speed. I didn't realize that Heise came out with a variant more tailored to speed solving with the use of L4C ( similar to the Hahn method ).

I more curious at exploring older methods for speed solving similar to @efattah 's reexamination of Corners First methods ( and Waterman ? ).

It says Andy Camann used it in the early 2000s to achieve sub-17 times so I'm kinda just interested in if anyone else has follow up on this method since 2004 and how good it might be.
I've done some waterman, and there's a discord server link in my signature. I'm not fast at it (high 30s), but I can help a lot.
 

Silky

Member
Joined
Apr 5, 2020
Messages
874
I've done some waterman, and there's a discord server link in my signature. I'm not fast at it (high 30s), but I can help a lot.

That's amazing ! I'll definitely checking that out. Step 3a and 3b are really brilliant imo. I'm also interested in checking out Snyder as well, even though I think he's a hack.
 

Tao Yu

Member
Joined
Jun 29, 2011
Messages
1,172
Location
Ireland
WCA
2012YUTA01
YouTube
Visit Channel
These are just my opinions:

According to the speedsolving wiki, the steps of heise are:

  1. Create four 1x2x2 blocks (also called Heise blocks), making sure that one color appears on none of the blocks. This color will be the color of the last layer. Note that these blocks do not necessarily have to be paired together when they are built. One of these blocks should be just two centers and an edge.
  2. Pair up the 1x2x2 blocks, while simultaneously orienting the last-layer edges. Note that you will now have all of F2L minus a corner/edge pair finished.
  3. Create two corner-edge pairs, and then solve all of the edges and two corners. This is typically a very difficult step for beginners to solve.
  4. Solve the final three corners with a commutator

The first two steps are creating F2L minus one pair + edge orientation. The Heise approach to this seems a little odd for speedsolving purposes and looks to me possibly more suited to a slower solve or FMC attempts. I think something a bit simpler like
  1. Build a 2x2x2
  2. Build a 2x2x3
  3. Build F2L minus one pair while simultaneously orienting the edges
might be necessary to make the method reasonable for speedsolving while mostly remaining in the spirit of the original proposal. That said, I think the ZZ or Petrus approach to getting to EOF2L-1 might just be better.

The first part of step 3: create two corner-edge pairs is usually not too bad. The second part: solve all of the edges and two corners is often not very obvious. It is very easy to create a situation where you have solved the edges and two corners, except two edges are swapped. When this happens, the only way to solve the edges is using something like a J perm (because to swap two edges you also need to swap two corners as well), which is of course a lot of extra moves. To avoid situations like this, you often will need to solve the two corners and edges in a less intuitive way. While many of the techniques on Ryan's website are effective for avoiding these situations, it would not be good enough to have to figure these things out during a speedsolve. In my opinion you would probably have to make a list of almost all the possible configurations (up to some form of symmetry) you can get at this step and determine the intuitive or non-intuitive solution (many of the intuitive solutions are awkward to fingertrick) you intend to use for each case beforehand.

When you get to the final step, the 3-cycle, the fastest way is of course to use speed optimized commutators from top 3BLD solvers, as commutators that you come up on the fly are likely to be slow. There is probably no good way to avoid the worst case: 3 twisted corners, which requires two commutators instead of one to solve.

So I basically think it would be a very weird method for speedsolving. I would guess that it's probably almost impossible to beat plain OLL/PLL combined with a fast turning speed with the Heise approach to EOLSLL - I just don't think the movecount can be low enough to compensate for the increased difficulty of recognition.

A lot of the problems above are solved by having more time and being able to go back on moves, which is why Heise is a useful method for FMC. Using Heise for speedsolving feels like forcing a method into an application it was not designed for, and for which more practical speedsolving approaches exist for achieving the goals of each of Heise's steps.
 

Silky

Member
Joined
Apr 5, 2020
Messages
874
These are just my opinions:

According to the speedsolving wiki, the steps of heise are:



The first two steps are creating F2L minus one pair + edge orientation. The Heise approach to this seems a little odd for speedsolving purposes and looks to me possibly more suited to a slower solve or FMC attempts. I think something a bit simpler like
  1. Build a 2x2x2
  2. Build a 2x2x3
  3. Build F2L minus one pair while simultaneously orienting the edges
might be necessary to make the method reasonable for speedsolving while mostly remaining in the spirit of the original proposal. That said, I think the ZZ or Petrus approach to getting to EOF2L-1 might just be better.

The first part of step 3: create two corner-edge pairs is usually not too bad. The second part: solve all of the edges and two corners is often not very obvious. It is very easy to create a situation where you have solved the edges and two corners, except two edges are swapped. When this happens, the only way to solve the edges is using something like a J perm (because to swap two edges you also need to swap two corners as well), which is of course a lot of extra moves. To avoid situations like this, you often will need to solve the two corners and edges in a less intuitive way. While many of the techniques on Ryan's website are effective for avoiding these situations, it would not be good enough to have to figure these things out during a speedsolve. In my opinion you would probably have to make a list of almost all the possible configurations (up to some form of symmetry) you can get at this step and determine the intuitive or non-intuitive solution (many of the intuitive solutions are awkward to fingertrick) you intend to use for each case beforehand.

When you get to the final step, the 3-cycle, the fastest way is of course to use speed optimized commutators from top 3BLD solvers, as commutators that you come up on the fly are likely to be slow. There is probably no good way to avoid the worst case: 3 twisted corners, which requires two commutators instead of one to solve.

So I basically think it would be a very weird method for speedsolving. I would guess that it's probably almost impossible to beat plain OLL/PLL combined with a fast turning speed with the Heise approach to EOLSLL - I just don't think the movecount can be low enough to compensate for the increased difficulty of recognition.

A lot of the problems above are solved by having more time and being able to go back on moves, which is why Heise is a useful method for FMC. Using Heise for speedsolving feels like forcing a method into an application it was not designed for, and for which more practical speedsolving approaches exist for achieving the goals of each of Heise's steps.

Well said. To clear up some confusion ( I should have clarified more in the post ) I am talking about the Old Heise variant which takes a different approach to step three & four.

You build up to F2L-1 with edge orientation and with the FR edge correctly permuted. Then you use an algorithm to permute the FRD corner and simultaneously permute Last Layer Edges. Then you finish with L4C.

According to the wiki this was an earlier version of the Heise method, as well as the method that Andy Camann used to achieve his sub-17 averages.
 

Tao Yu

Member
Joined
Jun 29, 2011
Messages
1,172
Location
Ireland
WCA
2012YUTA01
YouTube
Visit Channel
Well said. To clear up some confusion ( I should have clarified more in the post ) I am talking about the Old Heise variant which takes a different approach to step three & four.

You build up to F2L-1 with edge orientation and with the FR edge correctly permuted. Then you use an algorithm to permute the FRD corner and simultaneously permute Last Layer Edges. Then you finish with L4C.

According to the wiki this was an earlier version of the Heise method, as well as the method that Andy Camann used to achieve his sub-17 averages.

Oh sorry, I actually wasn't aware that there was an even older version of Heise . I though old simply meant before the speed-heise variants.

Old Heise reminds me of ZZ-b, in which the idea is similar in that you solve the last F2L pair while influencing the edge permutation such that you reduce the number of ZBLLs you have to know. ZZ-b's phasing step seems a lot easier than Old Heise's solving of the edges though because you only need to make sure that opposite colors are opposite each other, rather than needing to remember if red comes before blue or blue comes before red, which you need to pay attention to when solving the top edges in Old Heise. ZZ-b does require twice as many ZBLL algs though. I would guess that if you're willing to learn the extra algs, ZZ-b would be a better option.
 

PetraPine

Member
Joined
Feb 15, 2020
Messages
705
Location
Somewhere i guess.
YouTube
Visit Channel
These are just my opinions:

According to the speedsolving wiki, the steps of heise are:



The first two steps are creating F2L minus one pair + edge orientation. The Heise approach to this seems a little odd for speedsolving purposes and looks to me possibly more suited to a slower solve or FMC attempts. I think something a bit simpler like
  1. Build a 2x2x2
  2. Build a 2x2x3
  3. Build F2L minus one pair while simultaneously orienting the edges
might be necessary to make the method reasonable for speedsolving while mostly remaining in the spirit of the original proposal. That said, I think the ZZ or Petrus approach to getting to EOF2L-1 might just be better.

The first part of step 3: create two corner-edge pairs is usually not too bad. The second part: solve all of the edges and two corners is often not very obvious. It is very easy to create a situation where you have solved the edges and two corners, except two edges are swapped. When this happens, the only way to solve the edges is using something like a J perm (because to swap two edges you also need to swap two corners as well), which is of course a lot of extra moves. To avoid situations like this, you often will need to solve the two corners and edges in a less intuitive way. While many of the techniques on Ryan's website are effective for avoiding these situations, it would not be good enough to have to figure these things out during a speedsolve. In my opinion you would probably have to make a list of almost all the possible configurations (up to some form of symmetry) you can get at this step and determine the intuitive or non-intuitive solution (many of the intuitive solutions are awkward to fingertrick) you intend to use for each case beforehand.

When you get to the final step, the 3-cycle, the fastest way is of course to use speed optimized commutators from top 3BLD solvers, as commutators that you come up on the fly are likely to be slow. There is probably no good way to avoid the worst case: 3 twisted corners, which requires two commutators instead of one to solve.

So I basically think it would be a very weird method for speedsolving. I would guess that it's probably almost impossible to beat plain OLL/PLL combined with a fast turning speed with the Heise approach to EOLSLL - I just don't think the movecount can be low enough to compensate for the increased difficulty of recognition.

A lot of the problems above are solved by having more time and being able to go back on moves, which is why Heise is a useful method for FMC. Using Heise for speedsolving feels like forcing a method into an application it was not designed for, and for which more practical speedsolving approaches exist for achieving the goals of each of Heise's steps.
I think creating a sort of p223 than square is the best approach for speedsolving. the main issue with heise is recognition times and if you can inspect p223 that is definitely improved.
by p223 I mean a couple of different possibilities:
1.normal 2x2x3
2.2x2x2, paired with a square that is one move away (like an R or B move or something)
3.A edge+center edge pair(white green edge for example) than 2 one move away squares.
- - -
than for 4.create last square
5.EO+repermutation
6.LS/LL
there are more beyond this but I think that repermuting of more types of psuedo blocks gets to complicated for solves.
I recently was doing some solves with only this variation (while using ocll pll) and got an 18.50 ao50
 

PetraPine

Member
Joined
Feb 15, 2020
Messages
705
Location
Somewhere i guess.
YouTube
Visit Channel
With that said, what is the best way to get to EO 2x2x3? Leor, Petrus, ZZ arrow, ZZ line, or something else? I have been wondering about this for a while.
petrus. (or LEOR for OH) blockbuilding after EO if restricted to 223 is really bad.(ergonomics wise) and Line works much more proficiently if you don't restrict yourself to always doing line+1x2x3(same with arrow).
 
Top