Stefan
Legend
I sometimes see someone writing about my method(s) and what its/their key idea is, and I just had an email conversation about it and figured I could describe my thoughts here as well. Partly because I've been wanting to write about this for a while anyway. So...
Some people say the key idea of my method(s) is that I combine orientation and permutation, and I strongly disagree. My key idea was and is:
"Solve one piece at a time"
With a heavy emphasis on "one piece at a time". Because I find setting up two (or even more) pieces hard, and when you just set up one piece it's much easier and there are so few cases that you can just *know* setups/algs for all of them. When I recall a memo element I can immediately execute without visualizing the cube and what I'm doing. It's a direct translation from memo to execution. Like when you read a book to someone you don't really have to think about what you're reading, you can just read the letters and you just know how to move your mouth to say what you read.
The "solve" part of the statement means, well, to solve a piece. Put it exactly where it belongs. And of course not in a wrong way. But I don't think I combine orientation and permutation. Instead I think I do not separate them. Subtle difference. I consider "solve" the natural thing and the separation artificial. I'd say thinking my key idea was combining orientation and permutation, that's only a historical misconception, as previously people did them separately. But that wasn't and isn't my key idea, which is working on just one piece at a time instead of several. Which made it so easy that as sort of a *side effect* it also allowed me to do orientation and permutation together.
So I'd say separating orientation and permutation but working on one piece at a time, that fits my key idea, but doing orientation and permutation together and working on two pieces at a time, that doesn't. That said, I don't have anything against solving two pieces at a time. It has its advantages, just like solving one piece at a time does. Likewise I have nothing against doing orientation and permutation separately. That also has its advantages, just like doing them together does. Gets rid of the lone just misoriented pieces right away and also makes at least M2 faster because you get all the nice cases. Everybody needs to figure out what works best for themselves.
It's not really that important, but it's been bugging me a bit and I just wanted to clear it up and also shed some light on the history and the thinking in the development process the method(s) went through.
Some people say the key idea of my method(s) is that I combine orientation and permutation, and I strongly disagree. My key idea was and is:
"Solve one piece at a time"
With a heavy emphasis on "one piece at a time". Because I find setting up two (or even more) pieces hard, and when you just set up one piece it's much easier and there are so few cases that you can just *know* setups/algs for all of them. When I recall a memo element I can immediately execute without visualizing the cube and what I'm doing. It's a direct translation from memo to execution. Like when you read a book to someone you don't really have to think about what you're reading, you can just read the letters and you just know how to move your mouth to say what you read.
The "solve" part of the statement means, well, to solve a piece. Put it exactly where it belongs. And of course not in a wrong way. But I don't think I combine orientation and permutation. Instead I think I do not separate them. Subtle difference. I consider "solve" the natural thing and the separation artificial. I'd say thinking my key idea was combining orientation and permutation, that's only a historical misconception, as previously people did them separately. But that wasn't and isn't my key idea, which is working on just one piece at a time instead of several. Which made it so easy that as sort of a *side effect* it also allowed me to do orientation and permutation together.
So I'd say separating orientation and permutation but working on one piece at a time, that fits my key idea, but doing orientation and permutation together and working on two pieces at a time, that doesn't. That said, I don't have anything against solving two pieces at a time. It has its advantages, just like solving one piece at a time does. Likewise I have nothing against doing orientation and permutation separately. That also has its advantages, just like doing them together does. Gets rid of the lone just misoriented pieces right away and also makes at least M2 faster because you get all the nice cases. Everybody needs to figure out what works best for themselves.
It's not really that important, but it's been bugging me a bit and I just wanted to clear it up and also shed some light on the history and the thinking in the development process the method(s) went through.
Last edited:
)?
