Web-based gripper: Finds fingertricks! (in theory)

badmephisto

Veteran
Joined
Aug 29, 2007
Messages
836
YouTube
Visit Channel
Alright. Some of you may recall my Gripper application that I created a few weeks ago that tried to find fingertrick-friendly versions of algorithms. The problem of course was that it was not easily accessible to normal joe, and the costs for each rotation and stuff were not easily modifiable. So here you go, I present you with a Web-based Gripper!

http://www.badmephisto.mine.nu/cgitests/

Go there, enter an algorithm, and have it analyzed right in your web-browser! The program will take the algorithm (that does not contain any rotations and double layer turns or MSE's) and output algorithm variations that it thinks are good.
Best of all, you can change up the costs in any way you like! So you are encouraged to help me and others find costs that work well for analyzing algorithms in general. The entire configuration is stored in the URL, so if you stumble by some configuration that seems to work well, you can post it here and we can all take a look at it, hack it up, and work with it. If you stumble by some good variations for some alg, post it too im curious :)

anyway let me know what you guys think.
One more thing: This program currently runs on my crappy web server at home so be gentle with it. Try not to set the depth too high, especially for long algorithms.
And one more thing: There will most definitely be some issues and potential bugs, i'm just a man. Post it here and I'll try to figure out whats going on. The project is pretty giant by now :p
 
URL, so if you stumble by some configuration...

It took me a while to realize, that URL doesn't mean up right left ;).

Anyway, great work, i'll give it a try with some of my awkward bld algorithms.

/edit: it gives me "the alg is not well formed" all the time. Even if i copy your example.

And what does "depth" mean?

/edit2: works now, thanks :)
 
Last edited:
G1 is thumb on R, fingers on B
Shouldn't that be 'F'?

L-moves are missing.

And what does "depth" mean?
Seems to be the number of cube rotations and double layer turns.

You are right that should be F thank you. fixed.
and you are right about depth as well. I added comment to make it clearer.

oh and L moves are missing because of the way the program works. It actually kinda makes sense. When you have to execute an L move, the program creates a "regrip" and it mirrors the entire algorithm, pretending that your left hand is now your right hand. So really, the cost of L is the same costs as cost of R'.
(this is not exactly true because a small cost penalty is applied to every move you make with left hand, because left hand is slower than the right hand... I may add the ability to modify this penalty later on. I just added it so that the program prefers RU heavy algs to LU heavy algs)
 
Last edited:
I have to say, I was expecting little in terms of new algs that are "friendly" to come from this program. I'm not sure why; I'm just being honest.

So I fed it one of my "problem" algs; one that I use whenever it comes up, but hate it just the same. It's an E permutation:

L U' R D2 R' U L' R U' L D2 L' U R'

In my searching it's the E perm I liked the best, and it still sucks. So gripper went town on it, and gave me something like 25 new algs to try. #1 ends with a u' and I don't like double layer turns, especially on U. #2 has r2s in it, and they're my favorite double layer turn if I have to use one. I tried it a few times and ... I'll be damned, but it's a good alg!!! I think I'm replacing my E perm with #2, which is:

z U R' D r2 U' R D' U R' D r2 U' R D'

So, this first test was a raging success! Nice job badmephisto. :) Full URL for anyone interested:

Big long URL for analysis of my E perm

Brian.
 
see the thing is that you cant really say the program sucks, because the program is just ... an algorithm... its output is really only a function of its input, which you provide. So if you are getting wrong results, there is no reason to blame the algorithm... you have to blame yourself for failing to provide correct costs for each turn :) Which is of course by no means a trivial task, but in my opinion it is far more manageable than going through 100 algorithms that are spit out of a program and trying to simplify them at leisure.
 
I think the program is great! The only thing is that I have no clue how much time it takes for me to do each turn. What would be a good way to find that?
 
I think the program is great! The only thing is that I have no clue how much time it takes for me to do each turn. What would be a good way to find that?

I was thinking of some empirical process to determine those exactly, by somehow presenting multiple algorithms that are only slightly different, timing myself doing each 10 times and then isolating the small parts somehow to get exact costs, but i dont think it would work too well... im not sure.

right now the way I use it is pretty arbitrary. I run it, and then decide that it thinks regrips cost too much or something, so I adjust the cost on that. Then I see that it used a b' which is terribly slow, so ill crank up the cost on that one and re-calculate, etc.

you bring up a good point, and i dont know
 
see the thing is that you cant really say the program sucks, because the program is just ... an algorithm... its output is really only a function of its input, which you provide. So if you are getting wrong results, there is no reason to blame the algorithm... you have to blame yourself for failing to provide correct costs for each turn :) Which is of course by no means a trivial task, but in my opinion it is far more manageable than going through 100 algorithms that are spit out of a program and trying to simplify them at leisure.

I'm guessing this was a response to me? If so, I didn't express myself properly the first time. I was trying to say this:

1. I had low expectations for this program for whatever strange mental reason.
2. I gave the program my current "E permutation", which I hate. I find the E perm (which I got off of a web site) to be hard to use and I dislike it.
3. Gripper gave me a *great* alternative, exceeding my expectations and making me very happy!
4. Congratulations on a job well done Badmephisto. :)

I hope my communication is more clear now.

Brian.
 
see the thing is that you cant really say the program sucks, because the program is just ... an algorithm... its output is really only a function of its input, which you provide. So if you are getting wrong results, there is no reason to blame the algorithm... you have to blame yourself for failing to provide correct costs for each turn :) Which is of course by no means a trivial task, but in my opinion it is far more manageable than going through 100 algorithms that are spit out of a program and trying to simplify them at leisure.

I'm guessing this was a response to me? If so, I didn't express myself properly the first time. I was trying to say this:

1. I had low expectations for this program for whatever strange mental reason.
2. I gave the program my current "E permutation", which I hate. I find the E perm (which I got off of a web site) to be hard to use and I dislike it.
3. Gripper gave me a *great* alternative, exceeding my expectations and making me very happy!
4. Congratulations on a job well done Badmephisto. :)

I hope my communication is more clear now.

Brian.

nonono my comment was strictly aimed at your comment about low expectations from the program :) I am very flattered by your compliment of course. The program did take a long time to write...
imo, that E perm you found still kinda sucks :p
I use this: x' (R U') (R' D) (R U R') u2 (R' U) (R D) (R' U' R), i find it flows nicely. Here are 2 more e-perms I got from gripper, havent looked at them yet
z' R U' R2 F' R D R' F R2 U R' F' u' R
u' R' F R u z' U' R2 F' R D' R' F R2 U
 
Last edited:
There should be some sort of restrictions.
For example:
RB is fast, but R'B is slow.
RF' is fast, But UF' is slow.

Yet for most cases, R = R' = U = U' in speed.

Some special combos of moves can be very fast, yet their individual parts maybe slow by itself.
 
There should be some sort of restrictions.
For example:
RB is fast, but R'B is slow.
RF' is fast, But UF' is slow.

Yet for most cases, R = R' = U = U' in speed.

Some special combos of moves can be very fast, yet their individual parts maybe slow by itself.

But of course that's implemented. This program doesnt just naively count the characters :p It actually has a pretty complicated system of determining what is fast or slow.
RB would be flagged as fast if you start in Grip1. Because R would move you to grip2 which makes your index be at perfect position for B. So B, done in Grip2 is quick. However, if you are not in Grip2 and you must do B, the program sees that it needs to regrip first to grip2 and then do the B, so it will accumulate cost because of the regrip.
cost of RB starting at grip1 = cost(R) + cost(B)
cost of R'B starting at grip1 = cost(R') + cost(regrip from 0 to 2) + cost(B)
 
I know that this is quite a large bump here - over a year in fact, but a few others and I were wondering if anyone happens to have this, either in source, binaries, the actual page running the scripts. Pretty much anything, really.
Any version would be very much appreciated; if we do manage to find this, there's a good chance that their could be a linkage to aCube or CE implemented.

Thanks in advance,
-Stachu
 
he doesn't have the code. Stachu said he lost it when he switched servers (as you can see by the dead links in the first post)
Stachu Korick September 7, 2009 at 7:45pm
I can't seem to find your Gripper program, and would really like it for something that I'm working on. Any chance of you sending me a link to either the webpage or the source?

****** ******** September 7, 2009 at 10:04pm
I took it offline because I stopped using my home computer as a web server. So it is gone forever. I dont have easy access to the source anymore.




^^old Facebook messages.
 
Back
Top