# Massive algorithm-database useful?



## Sakarie (Aug 2, 2010)

There are a lot of people that knows BH/commutators for edges and corners now, which is great! At least for me, I thought that that would be the final method-destination,and that I wouldn't need to learn another algorithm after that. Now I know I'm wrong.

What I want to do is to take every single three-cycle, and find the speed-optimal algorithm/-s for it! How great wouldn't that be?

I obviously can't do it alone, but is anyone else interested? The best way is using the wiki, and creating something like "Cycle UF->UR" and then list all 20 possible ends to that cycle, and everyone could submit their fastest algorithm/-s for 3x3. 

Everyone not using the same buffer would be a problem, but since i _think_ that UF is the most usual, we could start there, and the continue with UR or something. Since edges have a lot of more possibilities, I'd say that's more useful.


----------



## riffz (Aug 2, 2010)

Yes. There aren't nearly enough catalogued blindfold algs and I think this would benefit the community greatly.

I wish there were a better way to sort them, though. Sorting by buffer would seem a better idea to me, but then there would be duplicate alg lists for different buffers and they would quickly become inconsistent.

Your idea for sorting is also good, Sakarie, but what if someone wanted to find algs for UR->FL->UF? It would be kind of a pain to shift their cycle until they found a link to take them to UF->UR->FL.


----------



## Sakarie (Aug 4, 2010)

riffz said:


> Yes. There aren't nearly enough catalogued blindfold algs and I think this would benefit the community greatly.
> 
> I wish there were a better way to sort them, though. Sorting by buffer would seem a better idea to me, but then there would be duplicate alg lists for different buffers and they would quickly become inconsistent.
> 
> Your idea for sorting is also good, Sakarie, but what if someone wanted to find algs for UR->FL->UF? It would be kind of a pain to shift their cycle until they found a link to take them to UF->UR->FL.



How many different mainbuffers do (different) people have? UF and UR, some probably UL and UB, but I'm not sure if there is any other. DF maybe, if you're converting M2 to freestyle. Anyway, it wouldn't be that much more digital space needed, and the algorithms would be the same, so not much effort for neither hardware nor humen. 

I'm kind of disappointed that there weren't that many people wanting to help, but I guess maybe people will join in on the way (I'm *not *disappointed in the people not wanting to help). But I'm afraid the point to simply share algorithms wouldn't be as good if we're only two.

What's your main buffer, riffz?


----------



## MiloD (Aug 5, 2010)

Did someone mention sorting blindfold algs? I have been working on this spreadsheet for corners with UBL buffer. The colors represent shapes that I use for memo. There's 3 group types 36 groups and 3 sub groups. I'm almost done filling in all the cells with comments to show the commutator when the mouse is over the cell. This sheet has taken many hours.

sort of looks like my avatar


----------



## riffz (Aug 5, 2010)

Sakarie said:


> riffz said:
> 
> 
> > Yes. There aren't nearly enough catalogued blindfold algs and I think this would benefit the community greatly.
> ...



That's a good point. I was thinking you intended to have a database for literally every cycle, but we could start off with only a few buffers. I currently use DF as my buffer because I'm lazy and I use M2 for any cycles I can't think of right away. I'm not sure if I'll switch or not. I'm working on optimizing all the bad cases, and you can still take advantage of all the nice <R,U> algs just by doing x first.

As for corners, ULB all the way, and I'd really like to share my algorithms if other people are willing to contribute. If no one else is interested we could just use email.


----------

