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 ?
Old Heise as a Speedsolving Method?
- Thread starter Silky
- Start date
D
Deleted member 51471
Guest
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.
NeoBridgeburn
Regular
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
Sent from my Walton Refrigerator using Tapatalk
@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 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.
D
Deleted member 51471
Guest
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
Veteran
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
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
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
Veteran
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
Veteran
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
carcass
Veteran
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.
PetraPine
Veteran
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).
