# Tripod Method



## ostracod (Feb 14, 2009)

...A long time ago, I used my own method for solving the Rubik's cube, the Fridrus method (2x2x3 block, 2 edges, 3 c/e pairs, 5 piece LL).

Then Qqwref (Michael Gottlieb) gave me a lot of useful insight. He recommended that I use pure block building, and so I learned the Tripod method (2x2x2 block, 3 2x2x1 blocks, 1 c/e pair, 5 piece LL). (He also persuaded me to make my first block like a normal person... It was like I was living in a cave before!)


And so I worked and worked on this nice little method. I like it a lot, because you don't have to memorize many algorithms, and it relies more on intuitive thinking. The last layer (which contains 3 corner pieces and 2 edge pieces) can be solved in 2 steps with 6 memorized algorithms.

You can see the method specifics on my site:

http://web.mac.com/teisenmann/Tripod/main.html


Recently, I have been wondering what the essential differences between the Tripod method and Fridrich method are. The cross and first 3 c/e pairs can be used in both the Fridrich method and Tripod method for the first few steps (although I like block building better!). After the cross and 3 c/e pairs, the methods differ:

With Fridrich, you solve the last c/e pair, then solve the 8 pieces in the last layer using algorithms.

With Tripod, you solve a 2x2x1 block in the last layer, THEN the last c/e pair, and finally the 5 remaining pieces w/ algorithms.


...So now I have a couple questions.

If you want to memorize a SMALL number of algorithms, is it faster to use the Tripod method? In other words, is intuitively solving a block faster than algorithmically solving the entire LL? (Keep in mind that solving the last c/e pair in Tripod is more restricted.)

And alternatively, if you want to memorize a LARGE number of algorithms, is Fridrich faster? A 1 step LL in Tripod and 2 step LL in Fridrich require about the same amount of memorization (I haven't found the actual amount, because I don't want to memorize a lot! )

Comments are welcome!


----------



## Stefan (Feb 14, 2009)

I don't understand step 5. Can you tell exactly how to solve let's say this case?


----------



## ostracod (Feb 14, 2009)

If you have the case which you have given, you first do R' F R F'. Then you have one of the first cases listed on my site. You could either re-orient the cube and solve the case using the same mini algorithm, or you could re-orient the algorithm, and do F' U F U'. Now you have your corner edge pair. Lastly, you do F R' F' R to put it into place.

It's important to note that the mini algorithm can be done very fast with finger tricks... In about half a second! R' F is done with one hand motion (right wrist turns down and index finger turns F), then as R moves back up, the left index finger pushes F back as well.


----------



## Stefan (Feb 14, 2009)

Ah yes, that works. I think it would be good to have the cases grouped precisely by number of Frifris, i.e., first all cases with 1, then all with 2, etc. And I'm not convinced all cases are covered. Are they?


----------



## ostracod (Feb 14, 2009)

The cases actually are already grouped by number of Frifris, in the way you described... Except not counting the c/e pair placement, which I suppose would be useful.

I'm fairly certain that all cases are listed (mirror cases are not included). If you think a case is missing, tell me.


----------



## Stefan (Feb 14, 2009)

I didn't have a missing case, it was just not clear to me that all cases are covered. After thinking/checking a bit, I think you got all. Though I still think it would be nice to have that proven on the page, at least somewhat.

This picture is wrong, btw:
http://web.mac.com/teisenmann/Tripod/main_files/9__$!%40!__pastedGraphic.png

And yes, the pair placement placements would be nice to have, too.


----------



## ostracod (Feb 14, 2009)

Whoooops! Didn't see that, thanks. I'll consider adding a c/e pair case section. It takes 1 or 2 Frifris to place the corner edge pair, depending on the case.


----------



## ostracod (Feb 16, 2009)

I'm not sure if anyone's following this thread anymore... But I think I found a way to eliminate half of the tripod last layer permutations.

Normally there are 5 pieces in the tripod last layer, with a little over 100 possible permutations. But when placing the last c/e pair, it is possible to orient the edges by adding a few more moves. With this technique, there would only be 50 permutations, and half as many algorithms to memorize as before! I think I'll try using this trick for a while to see if it is helpful.

...If anyone is curious to know how to orient the edges for the LL, just ask.


----------



## Lucas Garron (Feb 16, 2009)

http://web.mac.com/teisenmann/Tripod/main.html said:


> Frifri is simply R'F R F


Is that supposed to make sense?


----------



## ostracod (Feb 17, 2009)

"Use the mini algorithm "Frifri" to solve a corner edge pair in the tripod. Frifri is simply R'F R F'."

That seems pretty clear to me... Frifri is the name of a mini algorithm, which is R'F R F'.

When you have a Tripod of unsolved pieces, Frifri is the ONLY move you can do without messing up everything... without using algorithms (or commutators). The key to using Frifri is learning the cases in which it pairs a corner and an edge together.

Alternatively, you could solve the Tripod using only algorithms, but that defeats the purpose of having a small number of algorithms to memorize.


----------



## dChan (Feb 17, 2009)

I think he means that "Frifri" is a techincally wrong name for that algorithm. Because if you really think about it, it should be "Rifrfri", right?


----------



## Samlambert (Feb 17, 2009)

dChan said:


> I think he means that "Frifri" is a techincally wrong name for that algorithm. Because if you really think about it, it should be "Rifrfri", right?



Using that logic it would be Rifrfi so lets just call it Frifri okay? haha


----------



## ostracod (Feb 17, 2009)

I never thought of the name like that before. :O But yes, I guess it would make sense to call it that. The origin of the name "Frifri" came from the Fridrus method, and is just a repetition of "Fri".

I'm making a table right now to find out how many algorithms one would need to memorize for a 1 step "nicer" last layer. I'm excluding cases in which commutators can be used...


----------



## dChan (Feb 18, 2009)

Ah, I see, that makes more sense now. I thought the name was based on the algorithm itself, but now that I know where it comes from it doesn't seem so out of place.


----------



## James Kobel (Feb 18, 2009)

I thought of the same method a while back, the difference was that I used no algorithms at all, even for the last layer. It really isn't that hard. But if you really want last layer algs, go here- http://www.ws.binghamton.edu/fridrich/L1/ece.htm


----------



## ostracod (Feb 19, 2009)

Yes, I've greatly appreciated that source since I found it a while back (Thankyou Jessica Fridrich!!). The only problem that I find is that all of the algorithms are given as if the last layer were on the F side (I assume she holds it higher so the front is closer to her face?), so I have to reorient them for a U side LL. But it's convenient to have all the "nice" last layer algorithms in one place.

With edges oriented in this kind of last layer, one has to memorize only 17 algorithms if he/she knows how to do commutators and a corner twisting technique. The solver will then be able to solve the last layer in 1 algorithm. I am definitely going for this!... After the craziness in school theatre is over though. >_>

James, I'm interested in how your approach works. Is it somewhat like the Heise method, where you place all edges and 2 corners, then solve the rest w/ commutators? Or something different?


----------



## James Kobel (Feb 19, 2009)

It really varies, mostly I would pair up a corner and an edge in 1-3 moves then place it while putting whatever I disturbed back, leaving either 2 misoriented corners or a solved cube. It was really just conjugates.


----------



## ostracod (Feb 19, 2009)

You do this when there are 5 unsolved pieces left? How do you join pieces without destroying other things?? ¿_? I thought Frifri was the limit of c/e pair creation/placement, because one can do R' F R F' without disrupting solved parts of the cube. I would really like an example!


----------



## Dirk BerGuRK (Feb 19, 2009)

I hope this hasn't been discussed before, but I glanced through the site and posts and didn't see anything. What is the average move count you are getting with this method?


----------



## ostracod (Feb 19, 2009)

I haven't done a precise move count lately, but I find it has a low move count (block building tends to be very efficient). Perhaps Frifri adds a few extra moves, but if one could learn a 1 step last layer (w/o edges already oriented), the move count would be very low. I'd say it's comparable to the Petrus method in moves, maybe a bit more to be conservative.


----------



## ostracod (Feb 20, 2009)

For the Tripod method, the minimum number of algorithms to know (if you can do commutators like in the Heise method) is 2. One fixes parity, the other orients edges, and then you solve the 3 corners.

...And again, if you know how to orient the LL edges during the last c/e placement, you only need to know 1 algorithm as a minimum!

I suppose you could argue that the Fridrich method also requires 2 algorithms for a bare minimum (2 to solve edges, commutators for corners). However, if you only knew 2 algorithms, it would take a considerably long time to solve the last layer...


----------



## ostracod (Feb 22, 2009)

Yes, Frifri is a technique which is very tedious until you master it. When I first started using Frifri, I didn't know any of the cases, so I would keep doing it randomly until a c/e pair appeared! Then as I kept using the Fridrus method, I found the first 3 cases which would pair a corner and edge in 1 Frifri. It wasn't until recently that I found the rest of the cases.

I know all of the cases now, and as a result I can pair any given corner and edge in a tripod pretty fast, in under 5 seconds (keep in mind that my total solve time is about 55 seconds). Then the c/e pair placement is fairly straightforward... unless you are also orienting the remaining edges simultaneously, which takes a couple more seconds.


----------



## ostracod (Feb 27, 2009)

Sorry to bump this, but i've just made a new (better) video for the Tripod method.

http://www.youtube.com/watch?v=BJgmVH2bzU8


----------



## ostracod (Feb 28, 2009)

Weeeww triple post. :U

I just found a way to make the Tripod method algorithm-less. During the Tripod step, if you only use Frifri then by definition you preserve any parity (whether there is an odd number of edge swaps). There is a lengthly maneuver which can fix the parity during this step, which involves breaking up one of the blocks and putting it back together in a different way (using an odd number of quarter turns to eliminate parity). This move is U R U' R' U2 R U R' U R U2 R' U'... After that you solve a corner edge pair (while orienting edges), and then you use a commutator to solve corners.

It doesn't seem very efficient for solving (speed or low move count!). It is a 2 generator though, which means one could probably do it quickly. At least it's useful for people who like to boast how they don't need algorithms.


----------



## Stefan (Mar 1, 2009)

ostracod said:


> it's useful for people who like to boast how they don't need algorithms.


By using an algorithm. Brilliant.


----------



## ostracod (Mar 2, 2009)

I suppose one could call it an algorithm... But it's easy to see how it works (that is, how it breaks up the block and puts it back together in an odd number of 1/4 turns). If you know exactly how a move sequence works, is it an algorithm?


----------



## Stefan (Mar 2, 2009)

ostracod said:


> If you know exactly how a move sequence works, is it an algorithm?


Yes, of course.


----------



## ostracod (Mar 3, 2009)

I don't mean to argue, but I'm interested in what the "true" definition of an algorithm is. The definition given on cubefreak.net is as follows:

"Algorithm
An agorithm is a sequence of movements which performs the same function everytime it's done, and which returns the cube to the staring point when repeated a certain number of times. For example: Start with a solved cube perform R U R' U R U2 R' U2. Done twice more returns the cube to the solved state. Start with a solved cube perform R U R' U R U2 R' U2 (same as the first but without the U2 at the end). Done 5 more times returns to the solved state. (David Salvia)"

Could a commutator be considered an algorithm, because it's a sequence of moves which will eventually revert the cube back to normal (when repeated)? Or does the fact that the technique can be done in multiple ways (none of which are pre-defined) make it not an algorithm?

And similarly, is my really long useless set of moves an algorithm even though I can find multiple ways to do the same thing? For instance, the move sequence below also eliminates parity for the tripod. Like the last set of moves, it breaks up the block and re-assembles it in an odd # of 1/4 turns:

U R U R' U' R U' R' U2 R U2 R' U'

I would appreciate your thoughts!


----------



## Stefan (Mar 7, 2009)

ostracod said:


> "Algorithm
> An agorithm is a sequence of movements which performs the same function everytime it's done, and which returns the cube to the staring point when repeated a certain number of times. For example: Start with a solved cube perform R U R' U R U2 R' U2. Done twice more returns the cube to the solved state. Start with a solved cube perform R U R' U R U2 R' U2 (same as the first but without the U2 at the end). Done 5 more times returns to the solved state. (David Salvia)"


That's wrong, or at least not a "definition" of algorithm. Not in general and not in cubing. The whole part about returning to the starting point does not belong in the definition. It's only a consequence. Macky should've written that entry himself.

For the term "algorithm" in general, read the Wikipedia article, at least the first paragraph:
http://en.wikipedia.org/wiki/Algorithm

In the context of cubing, "algorithm" means "sequence of moves". We could also call whole methods like Fridrich or Petrus "algorithms", but we call them methods. It's nicer. Shorter and the distinction helps. There's also a page in our own Wiki here:
http://www.speedsolving.com/wiki/index.php/Algorithm

Many people think "It's not an algorithm if I can understand it", but that's junk. They just don't know the word "algorithm" and think it means something mystical (same as with "parity"). There's no reason to define it as "non-understandable", and that also doesn't work, because otherwise you might not understand some move sequence but someone else does understand it, and then it'd both be and not be an algorithm at the same time. Junk.



ostracod said:


> Could a commutator be considered an algorithm ...


Could? Should!



ostracod said:


> ... because it's a sequence of moves which will eventually revert the cube back to normal (when repeated)?


No, that has nothing to do with it.



ostracod said:


> And similarly, is my really long useless set of moves an algorithm


Set? You mean sequence. A set is unordered. But yes, what you mean is an algorithm. And no, it's not useless.


----------



## Wacky (Mar 8, 2009)

Wacky: 2. any sequence of moves when repeated over and will eventually return the cube to a solved state because of the pigeonhole principle and all that.
Stefan: Yes, that's what I meant with consequence vs definition. Oh and what you just wrote is not true. A cube away from solved by a D turn is never going to be solved by any number of repetitions of U R.

Edit by Stefan: Damn, I hit Edit instead of Quote and there's no Undo. Sorry, I'm new to being a mod. Wack commented on the above definition of "algorithm" and also said something like this:

1. "performs the same function everytime it's done"? Obviously. I've never gotten an R turn from doing an F turn.
3. Algorithm: Series of steps achieving some goal after a finite amount of time.


----------



## ostracod (Mar 9, 2009)

Ah, I'm happy that I now understand what an algorithm really is. It seems like an oxymoron to say that a method has "no algorithms", since (as you explained), a method ITSELF is an algorithm, or a series of steps that does something useful.

I have always thought to myself (inaccurately) that the Heise method uses no algorithms, but I didn't read the language on the site closely enough, which says it uses no *memorized sequences*... I feel like a naïve cuber. :X


----------



## gogozerg (Mar 9, 2009)

*I hate Jessica Fridrich*

In mathematics and computer science, an algorithm is a method that gives a solution to a problem, with a list of instructions.
It solves a class of problems, not just a specific problem with unique parameters.

Whatever the configuration, you need only 1 algorithm to solve the cube, and a solution is the move sequence the algorithm produced.
43,252,003,274,489,856,000 cases, 1 algorithm.

A mathematician would not say the optimal solution path in a graph, found by the IDA algorithm, is itself an algorithm.

It all started with the popularity of Fridrich's website I think. A whole dumb community is now using the word "algorithm" instead of just saying "move sequence", "sequence" or "formula".

Some people even call a random sequence that scrambles the cube, generated by an appropriate algorithm, a "scrambling algorithm"!

- "Try to repeat the RUR'U' algorithm as fast as possible".
- "What does it do?".
- "Nothing, it's just a fingertrick!".

Some will say that an algorithm does not have to be smart or generic, and that a cooking recipe or anything you can do in your life is an algorithm. So, why don't they actually use this word when cooking?
There are reasons to use words, and not just because they sound exotic.


----------



## Stefan (Mar 9, 2009)

gogozerg said:


> Some will say that an algorithm does not have to be smart or generic, and that a cooking recipe or anything you can do in your life is an algorithm. *So, why don't they actually use this word when cooking?*


Because it would be boring to use this one word for everything? Because using different words with more precise meanings/contexts helps communication?

Nothing wrong with calling our move sequences "algorithms", it's just a very narrow usage of the term, not a wrong one. But if you disagree and insist on your definition, you might want to edit the Wikipedia article and tell MathWorld that they're wrong.


----------



## gogozerg (Mar 9, 2009)

"Mathworld" says:



> The process of applying an algorithm to an input to obtain an output is called a computation.


and


> A computation is an operation that begins with some initial conditions and gives an output which follows from a definite set of rules.




Example that makes sense to me: Cube solving algorithm.
*) Input = Random cube configuration.
*) Computation = 
1. Apply step 1 of the generic cube solving algorithm that depends on input.
...
N. Apply step N of the generic cube solving algorithm that depends on input and previous steps.
*) Output = Solving sequence.

Example that does not make sense to me: "PLL U" algorithm (sequence).
*) Input = Since we already know we're dealing with a "PLL U" case, the only input I can see is the physical cube in such a configuration. Plus, the input never changes.
*) Computation = What computation? The only thing to do is to apply the dumb sequence.
*) Output = What is the output of the "computation"? Not the sequence, since it's the "algorithm", or part of it. The output may be the physically solved cube.

I certainly don't consider that performing physical actions (magic competitions, cooking, speed writing, etc.) belongs to the scope of algorithmic science.



> Because using different words with more precise meanings/contexts helps communication?



The problem is, I really can't see why it would be more precise.
What if I say: "Show me your move sequence for PLL U". Is it difficult to understand? What is the added value if you say "algorithm"?

Moreover, the way we use the word in data processing perfectly applies to cube solving. It's interesting to propose an algorithm (a well defined strategy) based on commutators for example.
Having an additional derived meaning (even worse, the word has lost it's very meaning) really is polluting.



> Nothing wrong with calling our move sequences "algorithms", it's just a very narrow usage of the term, not a wrong one.


As you understand, I still consider it's a wrong usage.
Stefan, most of the time, I value your opinions, so I want you to make me understand why it is a good word! Thank you.

(Media love this word, no matter what it means or what they think it means...)


----------



## Stefan (Mar 10, 2009)

gogozerg said:


> Example that does not make sense to me: "PLL U" algorithm (sequence).
> *) Input = Since we already know we're dealing with a "PLL U" case, the only input I can see is the physical cube in such a configuration. Plus, the input never changes.


Wrong, I can apply that same algorithm to a fully mixed up cube, so the input can differ vastly. And if you need it to "make sense" in terms of "helping to solve", just think about blindsolving and applying that alg in the middle or even at the start of the solve.



gogozerg said:


> *) Computation = What computation? The only thing to do is to apply the dumb sequence.


What computation? Well, let's look again at the MathWorld quote *you* provided:
MathWorld: _The process of applying an algorithm to an input to obtain an output *is called a computation.*_
And our "computation" is _the process of applying the algorithm to an input cube to obtain an output cube_.



gogozerg said:


> *) Output = What is the output of the "computation"? Not the sequence, since it's the "algorithm", or part of it. The output may be the physically solved cube.


Not necessarily a solved one, see my answer to the "input" issue and reconsider.



gogozerg said:


> I certainly don't consider that performing physical actions (magic competitions, cooking, speed writing, etc.) belongs to the scope of algorithmic science.


What if I physically, i.e., with pen and paper, use Euclid's algorithm for finding the greatest common divisor of two numbers? I could even do it without pen and paper, instead with two piles of cubes, trying to find the GCD of the number of cubes in the first pile and the number of cubes in the second pile. Is it not an algorithm anymore, just because it can be applied physically?



gogozerg said:


> > Because using different words with more precise meanings/contexts helps communication?
> 
> 
> The problem is, I really can't see why it would be more precise.


If you invite me to your place and cook for us and we're both eating and cubing and I say "That's nice, can you tell me the recipe?" then it's kinda clear that I'm talking about the food, not the cubing. Same as with "thing". I can surely say "Please hand me that thing", but saying "Please hand me the salt" is more precise.



gogozerg said:


> What if I say: "Show me your move sequence for PLL U". Is it difficult to understand? What is the added value if you say "algorithm"?


It's one word instead of two?



gogozerg said:


> Moreover, the way we use the word in data processing perfectly applies to cube solving. It's interesting to propose an algorithm (a well defined strategy) based on commutators for example.
> Having an additional derived meaning (even worse, the word has lost it's very meaning) really is polluting.


Let me take a step in the other direction. I've been thinking about a program enumerating and evaluating methods like Roux, Fridrich, Petrus, etc. So I'd have an algorithm *producing* these methods, and these methods would be merely the output of my algorithm, merely data. The lesson is, there's more than one level, and the move sequence level is btw still above the move level.



gogozerg said:


> > Nothing wrong with calling our move sequences "algorithms", it's just a very narrow usage of the term, not a wrong one.
> 
> 
> As you understand, I still consider it's a wrong usage.
> Stefan, most of the time, I value your opinions, so I want you to make me understand why it is a good word! Thank you.


Not saying it's a "good" word, just that it's an ok word. I do dislike that many of us were apparently first exposed to this word in cubing and don't know the broader scientific meaning. I first came across the word way before I saw it in cubing, namely while studying computer science and (re)inventing many algorithms in programming competitions. Many haven't had this exposure and thus have a flawed understanding of the word, which is a pity. Also, I hate it when the media covers cubing and they say "algorithm" and make it sound spooky as if it was something magical or highly complex.

I checked some old material from the early 1980s last night. Singmaster said "process", Bandelow said "maneuver", the Rubik's cube compendium said "process" or "sequence". Personally, "(move) sequence" would be my favourite because we'd never have to explain what it means, nobody would think it has a "non-understandable" connotation, and the media wouldn't make it sound spooky. But I have only little hope that our community as a whole could make the switch.


----------



## Athefre (Mar 10, 2009)

I don't know much math and the terms but I was first introduced to "sequence" as the alternate for "algorithm" by Gilles, then by David Salvia. After thinking for the past few years and a few times looking up the definition for "algorithm", I now agree with Gilles that "sequence" makes more sense (just based on the definitions I've seen and what I have thought of).

From Wikipedia:

_In mathematics, computing, linguistics and related subjects, an algorithm is a sequence of finite instructions_

From the definition above, it seems that "algorithm" and "sequence" are different words, it doesn't look like you can just take the part "algorithm is a sequence" and say that an algorithm is a sequence. I can see how you could read that line a different way and it would prove the rest of this post wrong but because of the definitions I've seen, in my mind a "sequence" is a group, and an "algorithm" is a group of groups. Or, another way of saying it is that you have an instruction (one thing to do, a point, one pixel, etc), more than one instruction is a sequence, and an algorithm is a sequence of sequences.



Algorithm said:


> 1. UM'UMU'l2U2r'U
> 2. x'rU2MUR2F'U2Fr
> 3. U'RUR'URU2R'
> 4. M'UMU'M'UM'UM'U2M'U'MU2M'
> ...



Then there is the word "Step" (group of cases) , in my opinion that would go somewhere next to the word sequence, you can't have more than one case at once can you?.

Again, I haven't studied much math yet so don't attack me  It doesn't matter to me that people say "algorithm", because I don't care and because I'm less knowledgeable about the word.


----------



## gogozerg (Mar 10, 2009)

You're right, you can look at the "PLL algorithm" this basic way:
*) Input = A cube configuration, random or not: C_in.
*) Computation = Application of the PLL move sequence.
*) Output = A different cube configuration: C_out=PLL(C_in).

But is it enough for a process to do something to something to be called "algorithm"?
There are many generic words that could potentially have been chosen for more or less good reasons: Method, routine, process, formula, function, action, etc. Or "(move) sequence" for the idea of sequentiality.
When we apply a stupid sequence, we are far from the world of effective methods that deal with class of problems or smart procedures.



StefanPochmann said:


> I do dislike that many of us were apparently first exposed to this word in cubing and don't know the broader scientific meaning. I first came across the word way before I saw it in cubing, namely while studying computer science and (re)inventing many algorithms in programming competitions. Many haven't had this exposure and thus have a flawed understanding of the word, which is a pity. Also, I hate it when the media covers cubing and they say "algorithm" and make it sound spooky as if it was something magical or highly complex.
> 
> I checked some old material from the early 1980s last night. Singmaster said "process", Bandelow said "maneuver", the Rubik's cube compendium said "process" or "sequence". Personally, "(move) sequence" would be my favourite because we'd never have to explain what it means, nobody would think it has a "non-understandable" connotation, and the media wouldn't make it sound spooky.


I agree totally.



> But I have only little hope that our community as a whole could make the switch.


That's why I hate Jessica. 
I started a new community of people who think before using the word "algorithm" on the french forum. Joins us!


----------



## Wacky (Mar 14, 2009)

Wacky said:


> Wacky: 2. any sequence of moves when repeated over and will eventually return the cube to a solved state because of the pigeonhole principle and all that.
> Stefan: Yes, that's what I meant with consequence vs definition. Oh and what you just wrote is not true. A cube away from solved by a D turn is never going to be solved by any number of repetitions of U R.



But I wrote that in the context of:


> *Start with a solved cube* perform R U R' U R U2 R' U2.


... sorry if that wasn't unclear. D'UR repeated over and over on a solved cube would eventually take the cube back to it's solved state.


----------



## qqwref (Mar 14, 2009)

Switching to "sequence" would probably be better from a strictly linguistic/mathematical point of view, but the problem is there isn't really a nice abbreviation for it. For "algorithm" we have "algs", which is short and unambiguous, but talking about "seqs" would just look and sound weird since it sounds just like another English word. Also saying "sequence" sounds kind of excessively formal to me... as if we're still trying to figure out the cube as a mathematical object, rather than solving it quickly as a sport. Maybe it's just the fact that there's no easy abbreviation I can think of.

An online thesaurus helpfully gave a list of terms meaning "sequence": "array, catenation, chain, concatenation, course, cycle, flow, grouping, ordering, procession, progression, row, run, series, streak, string, succession". There aren't too many good ones but I wouldn't feel too weird talking about a "move flow" or a "move string". Imagine, "What flow do you use for a Z-perm?" Sounds kind of futuristic-slang-y.


----------



## pinoycuber (Mar 14, 2009)

why everyone is arguing with the word ALGORITHM?


----------



## VersionXP (Dec 21, 2011)

This is my method,too!I created it in 2010,and i have the most algs of step3 by using CE this summer.And i used this method in fewest moves compitation in NanJing Autumn 2011,the result was 36 moves ,the first place,though this is my first FM compitation.l think the last two step may not very good ,if you use it in speedsloving.ah,next...my poor english


----------

