I have
no experience with memorizing a large quantity of algorithms, but I just thought about something when looking at Yo Notation. (
@abunickabhi , this does not at all mean that I'm not going to implement Yo notation into
your spreadsheet. But this could mean an additional feature which I could add to your sheet, if you want. I would just put the results of this "new feature" in its own separate column for experimentation.)
But suppose you have a 100k alg set in a spreadsheet. And suppose that:
- 10k algorithms have the same two moves U F (Singmaster notation) in them somewhere.
- 6k algorithms have the two moves R F in them somewhere.
- 1k algorithms have U M' U' in them somewhere.
The Excel spreadsheet can be coded (with VBA) to allow the user to come up with their own custom "partial algorithm substitution dictionary", where with the click of a button, they are given a list of the, say, 10 most frequently occurring 4 moves that occur in the entire 100k alg set. Then they can substitute every occurrence of those 4 moves (in all algorithms which contain them) with whatever they want. It could be a letter or a word. (For example, they could substitute "R U R' U'" with "sexy".)
They can do this
dynamically in time. Meaning that they only have to do replacements as they are memorizing the huge alg set. So this means that they don't have to get the list of "top 10 most frequently occurring 4 moves". They could (at any time) choose to substitute any
random 2-4 move sequence that they see in the current algorithm that they are memorizing and apply it to all algorithms which they haven't even looked at yet.
(So the algorithms in this
separate column will consist of a mixture of normal moves in Singmaster notation and their customly assigned substitutions.)
And they can (at any time) undo a substitution that they did previously (as long as the expressions/symbols/words they choose to substitute those moves with are properly chosen, of course.)
The advantage of doing this is to shorten the length of the algorithms.
In summary, the user could develop his/her own "language" to memorize an alg set. If this is done, then (in time) people can share their custom-made dictionary with everyone else
(I define "Yo Notation" as a 1-move substitution dictionary, but this idea is all about generalizing that to any number of moves and anyone's choice for the "words" in their dictionary), explaining the reason for each substitution they made so that eventually people will be able to see what is the best "dictionary" to use to "define" a particular algorithm set . . .
or simultaneously, people can learn what the best "dictionary" is for the majority of the alg set and
then find different algorithms for all cases in the set which that dictionary doesn't fit well -- so that the dictionary WILL then fit the entire set.
What do you think if something like this was implemented programmatically in, say, a programmed Excel sheet in VBA?
I got this "substitution logic" from looking at how compactly
@cuBerBruce wrote the
Hamiltonian circuit for the 2x2x2, for example. But unlike
that, which is compound substitution (in this case, where, for example, we substitute "sexy" for "R U R' U'" and "are you" for "R U" but then substitute "yep" for any occurrence of "are you sexy" in all algorithms), which is probably impractical for alg sets like this, but it could shorten the length of algorithms even more (but requires a play on word combinations . . . which is okay,
since this would be user-customized).
______________________________
On a completely different tangent,
Take the
UF5 algset, for example. Why not just choose algorithms which are all conjugations and/or slight modifications of a smaller set of algorithms? Again, I am not an expert on memorization, but as a concrete example, on pages 18-21 of
my F3L PDF, I show how all 211 algs can be broken down to essentially 14 algorithms (step-by-step).
So, if anything, you can have a handful of 5-cycle algorithms B_1, B_2, B_3, . . . , B_10 and then the "algorithms" for every one of the 100k cases could just be the conjugate moves A for a complete sequence [A, B_1], for example.
The algorithms would be
longer overall, but they would technically have to memorize far shorter algorithms, as it would just be the setup moves that they would have to memorize.
If this conjugation idea sounds good, this can be done (the alg set can be found) programmatically rather than manually, where the input would just be the base 5-cycle algorithms of your choice. If the minimum required setup moves to reach all UF5 cases is too long, you can give the computer
more base 5-cycle algorithms to use to reduce the number of required setup moves.