cage/cage variants sub minute average potential?

[TMOY]

of course I can very much use TMOY's centres method but I am rather skeptical about how fast it can really be...69 algs is a hefty load, and I wouldn't very much be able to use it for the 5x5. So right now commutators ftw..
any suggestions? bleah.

If you don't want to learn the full set of 69 algs, you can solve the centers in more looks with only a few basic commutators.
For the first step, you can place many center pieces with l u2 l' u2 and its variants (reversed, with l', r or r" instead of l, with d2 or E2 instead of u2) and finish with niklaas.
In some nasty cases, the alg l E' L2 E l' E' L2 E (which 3-cycles bars) may be useful too.
For the second step, solve the pairs of opposite centers the way you already described in one of your own posts.

 

[rachmaninovian]

As I have mentioned before, I am not going for any world record myself. If I was though, this is the way I would go about it.

First, I would make sure I had the best 4x4x4 available on the market. I have no idea what that would be, though I hear good things about the V cubes.

Regarding corners:

Whichever system works the fastest is the way to go. I would consider any method used by the top 10 2x2x2 solvers. If the system I end up using is one in use by one of the top 5 2x2x2 solvers, then I would be confident in sticking with it. If my system is not in use by the top 10, then I would have to strongly consider switching, no matter how much I was in love with my system. That's why I gave up Guimond.

Regarding the l and r edges:

I still think that the system which requires the fewest total moves is the best choice.

Regarding the centers, I think that the method I propose may be worth exploring, mainly because of the sheer brute force potential here. Brute force has worked very well for 2 look Last Layer solves on the 3x3x3.

If you were to use setup moves, you would need a whole lot of algorithms for the first center, but still a finite number.

Assuming that you are trying to solve the entire U center in one algorithm, and L and R centers are solved:

3 center cubies solved-
single center cubie on adjacent face
single center on opposite face

2 adjacent solved-
single on adjacent, single on opposite
single on adjacent, single on other adjacent
2 adjacent cubies on adjacent face
2 adjacent cubies on opposite face
2 diagonal cubies on adjacent face
2 diagonal cubies on opposite face

2 diagonal solved-
single on adjacent, single on opposite
single on adjacent, single on other adjacent
2 adjacent cubies on adjacent face
2 adjacent cubies on opposite face
2 diagonal cubies on adjacent face
2 diagonal cubies on opposite face

1 center cubie solved-
3 on adjacent face
3 on opposite face
2 adjacent on adjacent face, one on opposite face
2 adjacent on adjacent face, one on other adjacent face
2 adjacent on opposite face, one on adjacent face
2 diagonal on adjacent face, one on opposite face
2 diagonal on adjacent face, one on other adjacent face
2 diagonal on opposite face, one on adjacent face
one center cubie on each of the other 3 faces

0 center cubies solved
All 4 on adjacent face
All 4 on opposite face
2 adjacent on adjacent face, 2 on opposite face
2 adjacent on one adjacent face, 2 adjacent on the other adjacent face
2 diagonal on one adjacent face, 2 diagonal on opposite face
2 diagonal on one adjacent face, 2 diagonal on other adjacent face
2 adjacent on adjacent face, 2 diagonal on opposite face
2 adjacent on adjacent face, 2 diagonal on other adjacent face
2 diagonal on adjacent face, 2 adjacent on opposite face
3 on adjacent, 1 on opposite
3 on adjacent, 1 on other adjacent
3 on opposite, 1 on adjacent
2 adjacent on adjacent face, one on each remaining face
2 adjacent on opposite face, one on each remaining face
2 diagonal on adjacent face, one on each remaining face
2 diagonal on opposite face, one on each remaining face

39 algorithms, if I haven't missed any cases, and am counting correctly. We already use several of them. The only thing I would ensure while finding all the algorithms is that the opposite centers don't get disturbed during a direct center solve (so that you can use a subset of the 39 algorithms to solve the opposite face centers without messing up the first solved center).

Before giving up on this idea, consider how many algorithms an F2L solver must learn to do a 2 look last layer, or even the number of algorithms that you use for your l and r edges.

If you were to disregard center control while finishing the cage, and knew these 39 algorithms cold, you could save brain space on the l and r edge portion of the solve, and concentrate on crushing the centers in 3 algorithms.

That being said, I don't see how the best 39 algorithms can be found without a search program, so this proposed method will likely exist as a theoretical method only. I certainly don't have the time or patience to find them manually.

I will find the algs for the first 3 sets, because the last 2 sets is just redundant...you would want to try to solve the best first centre you can find i guess? =P
okay the first set is done already...2 sets to go =P
EDIT: 2 more algs..
2. 2 adjacent solved-
a) single on adjacent, single on opposite - r U' l' U r' U' l' U' r2 U l2 U' r2 U2
b) single on adjacent, single on other adjacent
c) 2 adjacent cubies on adjacent face - l' E l U2 l' E' l U2
d) 2 adjacent cubies on opposite face – r2 f2 r2 f2
e) 2 diagonal cubies on adjacent face – r U' l' U r' U2 r U l U' r' U2
f) 2 diagonal cubies on opposite face – l2 U r2 U' l2 U2 l2 U' r2 U l2 U2

3. 2 diagonal solved-
a) single on adjacent, single on opposite
b) single on adjacent, single on other adjacent – l' r' d l r U l' r' d l r U'
c) 2 adjacent cubies on adjacent face – y2 x' r U' l' U r' U2 r U l U' r' U2
d) 2 adjacent cubies on opposite face – x2 l2 U r2 U' l2 U2 l2 U' r2 U l2 U2
e) 2 diagonal cubies on adjacent face – U l' U' r U l' U' r' U r U' l' U r' U' l (per said that the fastest way to do it is 2 3-cycles..maybe with a cancelling move which i'm too lazy to try.)
f) 2 diagonal cubies on opposite face - U M' u2 M U' D' M' u2 M D

brute force...maybe optimal solutions would be better...but again I can't check for optimal solutions so these are it as of yet =P

 

[AvGalen]

First, I would make sure I had the best 4x4x4 available on the market. I have no idea what that would be, though I hear good things about the V cubes.

There are no V4's (yet?)

Regarding the l and r edges:

I still think that the system which requires the fewest total moves is the best choice.

Regarding the centers, I think that the method I propose may be worth exploring, mainly because of the sheer brute force potential here. Brute force has worked very well for 2 look Last Layer solves on the 3x3x3.

Can you explain why you think optimal algs are best for l and r edges, but suboptimal algs are better for centers?

But the big question remains: If you are going to develop a method that is meant to be used for speed, shouldn't it be faster than current methods?

 

[rachmaninovian]

this is what I believe: a system with better lookahead, and one with fingertrick friendly algs will pwn; you do not like 6gen 3x3 optimal algs right? 3gen is usually the preferred domain. I do not believe in optimal algs, but I do believe in fast algs.

I would also like to add another point: edge algs are still faster since its more face moves than slice moves. =P and since I have memorized and am unlikely to forget those algs I'd continue to use them to create easier centre cases.

and i believe cubacca1972 meant brute forcing USING a computer searcher to find all the algs required.

as far as I am concerned, my centre controlling algs have been producing better times although I have some lag while thinking of which alg I can use for the middle edges to purposely affect the centres. easy cases of centres are no longer lucky (well, not all the time...but once centre control had given me only 2 3cycles left to do after the cage, giving me a sub minute timing =P) besides I have made sure that all the algs I use are fingertrick friendly so I'm still pretty fast with either of them.

this is what I gonna do: make sure I squeeze every juice out of centre control before going to the next step of optimization. well, my R and L faces can still improve...but I guess it'll only improve slowly...

 

[cubacca1972]

I would define optimal algorithms as those which can be executed the fastest. Optimal algorithms might be the ones with the fewest moves, or the ones which are the most finger trick friendly, or both. Consider the sune. That pattern can actually be oriented with a 6 move algorithm, but it is rather awkward, and therefore not optimal.

The brute force aspect that I am refering to is having a mechanical, never fail, non-flexible method which always leads to completion of any phase in a specific number of steps. I mentioned the need for computer searches, because I worry that the algorithms found manually might not be optimal, as described above. Brute force also imples that there would be little to no creativity, style or elegance in solving the remaining centers, even to the point where you might be able to start with the same center, no matter what pattern you start with.

Can you explain why you think optimal algs are best for l and r edges, but suboptimal algs are better for centers?
?

I would think that optimal algs are required for all stages. If I have said something which implies otherwise, then thats not what I meant.

If a relatively solid set of algorithms could be found for the remaining centers, then center control during cage completion might not be as important.

That being said, if you happen to be able to control the centers while finishing the cage without ever needing to stop, think, anylize, execute, and this leads to a higher probability of the final centers phase being more optimal overall, then by all means, go for it.

But the big question remains: If you are going to develop a method that is meant to be used for speed, shouldn't it be faster than current methods?

Yes and no. It dowsn't necessarily need to be faster, just comparable in times. I do not believe that this method that we are messing around with will prove to be better or competitive unless the following happens:

1. Consistent sub 60 averages demonstrated.

2. Lots of 4x4x4 cubers adopting the method.

The first part is needed to attract others to using the method. The second is required to generate lower averages. I just don't see how world class times are possible with only one or two people using the system.

Think of the hundreds of Fridrich solvers out there vs the relatively few corners first or Roux method users out there. Is it really because Fridrich is the only viable method, or is it because most new speedcubers see what method has the most comprhensive material avialable, and gravitate towards it?

In the end, I would think that the most successful method will be the one which most of the talent gravitates towards.

 

[qqwref]

I just don't see how world class times are possible with only one or two people using the system.

Don't lose hope. I got UWR times on a few sizes of computer cube using my own centers last method, which nobody else was using. Try to get your delays down and your turn speed up, and try to look for situations where you can be more efficient, and of course don't forget to use ksolve (or something similar) to find short algs if you think you need them. If you believe that you are not capable of fast times with a non-reduction method unless other people help you out, well, then you won't be capable of fast times ;-)


By the way: the Meffert's 4x4s are the best ones I know of, so I'd really suggest buying one. The mechanism is the same as the old Rubik's 4x4s, which is much better with slice turns than the Eastsheen cubes.

 

[rachmaninovian]

I just don't see how world class times are possible with only one or two people using the system.

Don't lose hope. I got UWR times on a few sizes of computer cube using my own centers last method, which nobody else was using. Try to get your delays down and your turn speed up, and try to look for situations where you can be more efficient, and of course don't forget to use ksolve (or something similar) to find short algs if you think you need them. If you believe that you are not capable of fast times with a non-reduction method unless other people help you out, well, then you won't be capable of fast times ;-)


By the way: the Meffert's 4x4s are the best ones I know of, so I'd really suggest buying one. The mechanism is the same as the old Rubik's 4x4s, which is much better with slice turns than the Eastsheen cubes.

lol i only started 4x4ing again because of mefferts
is there any 4x4 solver out there? perhaps I need one to find optimal solutions to some of the more common centre cases which pop out of no where..wells...i've been using 3x3 solvers to simulate the middle edges...by removing all the edges and limit the corners to <r, l , U2, B2, F2, D2> normally I only generate algs for <r, U2, B2> if possible..i like B moves more than F =)
well i'm 6th on the UWR for 20x20x20 simply because no one bothers to spend time on it =P
back to topic i believe that with less lag definately sub 60 should be possible..with the help of solvers perhaps?

 

[qqwref]

I suggest ksolve. You'll have to make your own .def file for 4x4; I think it comes with one that just does centers, so you'll have to add edges and corners yourself, but that shouldn't be too tough if you look at the other .def files. But anyway then it will solve any position (allowing you to ignore certain things) optimally using the possible moves you've defined.

 

[AvGalen]

I would define optimal algorithms as those which can be executed the fastest.

No, you would REdefine what optimal algorithm means and confuse everyone else. Optimal is defined as fewest moves.

Consider the sune. That pattern can actually be oriented with a 6 move algorithm

Uhm, please tell me how to orient 3 corners in 6 moves.

 

[rachmaninovian]

how do I exactly use ksolve? I suck xD wells i can't open the .exe file...are u even supposed to open that? I can't find any way to open any damn file..

 

[DavidWoner]

Consider the sune. That pattern can actually be oriented with a 6 move algorithm

Uhm, please tell me how to orient 3 corners in 6 moves.

I'll do it in 3, instead of R U R' U R U2 R' try L B R

Now orienting 3 corners in 6 moves without destroying a bunch of stuff- I don't think it can be done. But please, prove us wrong.

 

[rachmaninovian]

random: per is lame : (R' D' R L z) * 4 xD

whee found better <r, U2, B2> algs to replace some of the nonfingertrick-friendly algs I've been using..

 

[qqwref]

You have to use ksolve from the command line, the usage is

ksolve [def-file] [scramble-file]

 

[rachmaninovian]

You have to use ksolve from the command line, the usage is

ksolve [def-file] [scramble-file]

Sorry to bother you...but it says can't open puzzle defination when I type this: Desktop\cube\ksolve\ksolve.exe 2x2 2x2test

or

Desktop\cube\ksolve\ksolve.exe [2x2] [2x2test]

 

[qqwref]

I'm pretty sure you need the extensions. First go to the directory ksolve is in (use cd if you're on Windows) and then the command looks something like
>ksolve 2x2.def 2x2-scramble.txt

 

[cubacca1972]

Consider the sune. That pattern can actually be oriented with a 6 move algorithm

Uhm, please tell me how to orient 3 corners in 6 moves.

I'll do it in 3, instead of R U R' U R U2 R' try L B R

Now orienting 3 corners in 6 moves without destroying a bunch of stuff- I don't think it can be done. But please, prove us wrong.

Sorry. Brief lapse in sanity. I remember doing a search a few years ago, where there was a shorter alg for a common pattern (obviously not the sune), but it was so awkward, that the longer sequences were easier to execute. That was the point I was trying to make. Please disregard the example.

edit:

R'UF2R2UF' (6,8)
R'DL2B2DF' (6,8)
L'BD2R2FR' (6,8)
R'DR2B2UR' (6,8)
L'FL2D2BR' (6,8)
R'UF2R2DR' (6,8)
L'FL2U2FL' (6,8)
R'DL2B2UL' (6,8)
L'BU2L2BL' (6,8)
R'UB2R2DL' (6,8)
R'UB2R2UB' (6,8)
R'DR2B2DB' (6,8)

These work if you are orientating the U layer corners, already have oriented D layer corners, but don't care about their permutation.

 

[cubacca1972]

No, you would REdefine what optimal algorithm means and confuse everyone else. Optimal is defined as fewest moves.

I suppose we could quibble with semantics, if you think it would be helpful.

If the way I use the word "optimal" really bugs you, just replace it with the following:

"the sequence of moves which can be executed the fastest"

 

[qqwref]

First off, if you're going to be discussing theory and finding algs, you should use words in the same way everyone else does. It's not "quibbling with semantics" as much as standing on the shoulders of giants. Making up your own definitions for words that everyone knows the meaning of is just as confusing as if you had decided to use K and Q to denote the l and r slices in your algs. Trust me on this: however much time you might think you will save by not having to switch to the standard notation/definitions/names, you will waste much more time than that trying to explain what you mean to other people who want to learn your method. Everyone uses "optimal" and "efficient" to mean having fewer moves; if you want to talk about what's the fastest to execute, it's better to call it "fast" or "fingertrick-optimal" or something along those lines, or make up your own term and explain what it means right off the bat.

Second, how do you know which moves can be executed the fastest? For instance some people are much faster with the RUR'F' J-perm while some are much faster with the RU2R'U'R one. There's no way to say which one is faster, but they are certainly not equal. So it's very hard to talk about a particular alg being faster than another. Besides, how exactly would you find out which ones are the fastest? You can't get all possible algorithms for a given case, just a bunch of the shortest ones.

 

[cubacca1972]

First off, if you're going to be discussing theory and finding algs, you should use words in the same way everyone else does. It's not "quibbling with semantics" as much as standing on the shoulders of giants. Making up your own definitions for words that everyone knows the meaning of is just as confusing as if you had decided to use K and Q to denote the l and r slices in your algs. Trust me on this: however much time you might think you will save by not having to switch to the standard notation/definitions/names, you will waste much more time than that trying to explain what you mean to other people who want to learn your method. Everyone uses "optimal" and "efficient" to mean having fewer moves; if you want to talk about what's the fastest to execute, it's better to call it "fast" or "fingertrick-optimal" or something along those lines, or make up your own term and explain what it means right off the bat.

Second, how do you know which moves can be executed the fastest? For instance some people are much faster with the RUR'F' J-perm while some are much faster with the RU2R'U'R one. There's no way to say which one is faster, but they are certainly not equal. So it's very hard to talk about a particular alg being faster than another. Besides, how exactly would you find out which ones are the fastest? You can't get all possible algorithms for a given case, just a bunch of the shortest ones.

Point taken. I will stick to "fast".

I would think that fast would have to be a relative term, dependent on the actual cuber. So yes, discussing which particular algorithm is faster for any case would be open to debate (as it is with any other solving method for any puzzle).

How would I find out which algorithm/algorithms are the fastest? I would prefer to use a search program to generate all optimal solutions, along with more solutions that are longer (how much longer? arbitrarily, 6 moves). Then I would test drive them to see which ones I can do the fastest. I would post the ones I thought were the fastest, and see if others felt the same way. I think that some candidate algorithms would stand out as being considered fast, by virtue of having the right combination of few moves and finger trick-friendliness.

The method I would least prefer would be to find a bunch of candidate algorithms manually, and going through the same process. This would simply take too long, and have a higher probability of missing fast algorithms (and optimal ones for that matter).

 

[rachmaninovian]

damn i can't run ksolve still...

This is what I've tried..
C:\Documents and Settings\Nicholas Ho\Desktop\cube\ksolve\ksolve 2x2.def 2x2test.txt

Then I get an error saying Pruning tables not found on file, computing. Can't open scramble file!
I guess i'm really dumb. xD

anyway..These few days will just be spent finding better algs for edge cases...i'm pretty much giving up on the centres system; for I see no future in it. After all it'll only save me 1 second or less per step..I rather work on lookahead..and clever 3cycling..and following the advice of blah...optimal commies will probably take too long to master...and wouldn't make too much of a difference xD