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.

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 ?

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.

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.

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.

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.

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

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.

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.

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.

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

Build a 2x2x2

Build a 2x2x3

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.

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

Build a 2x2x2

Build a 2x2x3

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.

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.