New 4x4 method idea

[elrog]

I have been looking for new ways to solve cubes, and every time I come up with something that seems promising, I find that it has already been thought of/done. I have looked on the internet for a HTA-like 4x4 method, and couldn`t find one. I would like to know if anyone has thought of this before, and I would like to know what everyone thinks of this idea. If I find that it hasn`t been done yet, I'd like to create one. If it has, then theres no point in me coming up with one. If you see this and make a method like it, please don't tell me because I'd like to figure it out myself.

 

[FourBias]

I guess u could try...

 

[aznanimedude]

as per your request, i will not aid you in your development or tell you any of the secrets

happy cubing HTA 4 eva

 

[vcuber13]

why not just solve it directly, reducing it seems like it would be a lot harder than 3x3 and solving with double turns could be very difficult with the centres and wings

 

[Michael Womack]

Theres this one that I made up http://www.youtube.com/watch?v=Kr37rWsEZMY

 

[elrog]

why not just solve it directly, reducing it seems like it would be a lot harder than 3x3 and solving with double turns could be very difficult with the centres and wings

HTA doesn't solve the cube directly, and it is a cool way to solve the cube while using few moves. I'm not quite sure what you meant by "centres and wings", but if you meant center pieces, they would be put into the correct circuits similar to how the corners are put into circuits in HTA. This method would probably not be great for speedsolving, but I can see it being using fewer moves than other methods. If you meant doing moves with the middle layers, then it wouldn't make it any more moves even though it takes longer (depending on your counting system).

Theres this one that I made up http://www.youtube.com/watch?v=Kr37rWsEZMY

This method you came up with isn't like what I was refering to. You did more of a belt mothod for the 4x4. I'm not quite sure what you were talking about with your parity, because you were first talking about it while talking about orientating the corners, but there is no orientation parity with corners. I'll assume you were talking about the permutation parity for corners. In the video, you did not have the edges solved yet so you wouldn't know weather that was actuall parity or not. On the 3x3, you can have 2 corners and 2 edges swapped, and it's not considered parity. Without having your edges solved yet, you wouldn't know if you had parity or not. One problem with the method that I see is its extremely high move count. Excluding the confusing parts of your video, it is a pretty neat idea and I encourage you to keep it up.

 

[vcuber13]

i know it does not solve it directly, hence i said why not.
prove it uses less moves than reduction, yau, or k4.
i understand the reduction, i mean the added orbits would make it more difficult to reduce and to solve with pi turns. on a 3x3 there are two types of pieces, on a 4x4 there are 4

 

[elrog]

Considering most popular 4x4 methods use about 120 moves minimum according to this wiki, I think I could manage finding a way with fewer moves. I said that about not direct solving to tell why to solve indirectly (about the same as telling why not solve directly). There are actually 3 kinds of peices on the 3x3 and 4x4. Both have centers, edges, and corners. I understand your piont though. The center piece circuits, I'm not to worried about because it would be much easier to recognize than corner piece circuits.

 

[vcuber13]

3x3 centres shouldnt be considered a piece in this context, it does not move and is not scrambled/solved. on a 4x4 reduce it the wings need to be in the correct orbits and can be considered separate pieces, if not it is still 3 to 2

 

[elrog]

I know, I just like to be difficult. I did say I got your piont though.

 

[Christopher Mowla]

Would a solution like this be similar to what you have in mind? It was from this post. If so then maybe you can make a variation of the solutions produced by cuBerBruce's solver which uses more moves but is easier to understand?

 

[elrog]

I tried looking at the links and the alg.garron. won't load. I did read the post though, and it seemed pretty interesting. I thought about lining up centers and edges at the same time, but I decided against it partly because it would take alot of time inspecting the cube, and partly because of much more difficulty avoiding parities. I did find out some pretty neat stuff just messing with the cube trying to get my idea to work.

I was thinking that I would get the centers into correct circuts, orient edges (this required matching edges up with other ones oriented the same way and it took less moves than normally matching edges). The top/bottom cross was done at the same time as orienting edges, then you would orient corners and place them into correct circuits as in standard HTA, next you match edges to correct sides, and lastly you solve with double moves.

I eventually decided not to do it this way because of parities during matching edges up with thier sides (trouble with edge circuits), and the fact that you might as well match edges up with the correct edge the first time. What I came up with was more like a reduction method made specifically for either HTA, or my version of the Orient First method (orient pieces as in HTA then f2l and pll).

First you get the top and bottom centers, next you match up side, front, and back center pieces with one other center piece of the same color giving you the rest of the center piecies in pairs (make the pairs line up in a horazontal direction), I then began edge pairing, but because of centers not lined up yet, you don't have to match them back up after every set of paired edges (I could orient edges while doing this because when I switched edges out to match other ones up, I turned my edges up the correct way so that they are oriented), combine this with my way to get past orientation parity while matching up last 2 edge sets, and you get a fewer moves way to math edges, centers, and orientate edges. After this is done, match up centers the same way you would the edges to opposite colors in HTA. Then, solve like normal HTA or my version of Orient First. Note that if you do HTA, you can match the centers up while matching edges up to opposite sides after the corners are oriented and put into circuits.

EDIT: Sorry, I looked at the wrong post, and now I feel like a moron. Yes cuBerBruce's solution is like what I was reffering to. Now I know this has been thought of, but I will still pursue my works because it hasn't been made in human version. When I solve with HTA, I think of it as more lining up certain kind of piece in thier circuits, rather than reducing a set of moves. That post has now gotten me aware of it and I'll see what I come up with.

EDIT 2: I think I've come up with a small improvement on the HTA method (the human version atleast). Ryan Heise's tutorial says that the easiest way to get corners into thier circuits is to seperate the top/bottom colored corners, find which need switched, and preform a simple algorithm. Then you align edges and solve with 180 degree turns. He also says that the easiest way to solve with doube turns is corners first. I think you would be better off to use PBL after you seperate out the top/bottom colors. You could then align edges and be on your way to solving with double turns, but the corners would be done already. Note that if you have the UF corner swap case, do the T perm, F perm, or turn the top and do A perm. This preserves orientation of the edges and the top/bottom cross. If you have the U layer Diagnonal swap, do the y perm, v perm, or n perm (It's best to do one other than the n perm). You do these for the same reason as with the UF corner swap.

EDIT 3: I came up with a way to make this method more like HTA than reduction for HTA. First, match up centers w/ opposite colors counting as the same and match thier circuits up. Orient the edges next (very similar to standard HTA edge orientation). Get the top/bottom cross. This requires some matching up, but only a few pieces because the top/bottom colors count as the same, and the edges are already oriented. Then you match up corner circuits as in HTA. Next you match up edges on opposite colored sides. It is a little harder to match up your centers at the same time this way than my other way because the edges are not matched up yet. Next, you find which edges are in the wrong circuits and switch them with 3 cycle edge commutators which will temporarily break edge orientation. Then you finish with double moves. It is alot easier to find which edges are in the wrong circuits by matching up which ones you can. If you just trace the circuits, then you can find them, but it takes longer. It will same many moves though. This can be done with the corners too (you wont have to seperate top/bottom color corners). It will take longer, but a few less moves. To improve this method further, I plan to come up with a way to place edges in thier circuits while orienting them.

 

[Christopher Mowla]

EDIT: Sorry, I looked at the wrong post, and now I feel like a moron. Yes cuBerBruce's solution is like what I was reffering to. Now I know this has been thought of, but I will still pursue my works because it hasn't been made in human version. When I solve with HTA, I think of it as more lining up certain kind of piece in thier circuits, rather than reducing a set of moves. That post has now gotten me aware of it and I'll see what I come up with.

Don't be hard on yourself! It will be interesting to see what you can come up with. Don't be afraid to take your time and test all of the possibilities. I have made many algorithms for 4x4x4 symmetrical edges, so if you need an algorithm or set of algorithms for some cases, let me know. If I cannot find the best algorithms, there are others here who might be able to help.

Also, if you didn't follow that thread beyond that post, cuBerBruce explains in a spoiler what the goal of the steps his solver are.

 

[Clarkeeyyy]

Sorry if this is a nooby comment but I've always thought: is it possible to remove the 3x3 stage from Yau/Reduction. What I mean is by careful placement of solved edge pieces, during edge pairing, you could somehow reduce the amount of work need after edge pairing is finished. Just a thought.

 

[Michael Womack]

Sorry if this is a nooby comment but I've always thought: is it possible to remove the 3x3 stage from Yau/Reduction. What I mean is by careful placement of solved edge pieces, during edge pairing, you could somehow reduce the amount of work need after edge pairing is finished. Just a thought.

That would work but not that easly. If we would remove the 3x3 stage from Yau/Redux the it would not be Yau/Redux

 

[cubernya]

If we would remove the 3x3 stage from Yau/Redux the it would not be Yau/Redux

No kidding.

On a side note: In terms of skipping certain steps of redux, I actually use a certain variation of this (skipping edge pairing). I solve centers and cross like in Yau, then just go strait into F2L without pairing the edges

 

[aznanimedude]

so Yau centers and then K4 rest of the way?

 

[ryanj92]

Sorry if this is a nooby comment but I've always thought: is it possible to remove the 3x3 stage from Yau/Reduction. What I mean is by careful placement of solved edge pieces, during edge pairing, you could somehow reduce the amount of work need after edge pairing is finished. Just a thought.

Losing sight of the topic here, but it just sounds like you're describing the K4 method

 

[vcuber13]

so Yau centers and then K4 rest of the way?

so K4?

 

[elrog]

Don't be hard on yourself! It will be interesting to see what you can come up with. Don't be afraid to take your time and test all of the possibilities. I have made many algorithms for 4x4x4 symmetrical edges, so if you need an algorithm or set of algorithms for some cases, let me know. If I cannot find the best algorithms, there are others here who might be able to help.

Also, if you didn't follow that thread beyond that post, cuBerBruce explains in a spoiler what the goal of the steps his solver are.

I dislike using algorithms, as I am a heise method fanatic. I do know some random/useful algorithms though. I know Pll, but 2/3rds of them are actually commutators. I also did read the thread up to that point, but not any farther. I didn't pay much attention to the spoilers, becaue they just had alot of rubiks cube notation. The notation just hurts my head to think about which symbol turn which side which way, especialy on big cubes. I did find that which sides he reduced and in what order though.

Sorry if this is a nooby comment but I've always thought: is it possible to remove the 3x3 stage from Yau/Reduction. What I mean is by careful placement of solved edge pieces, during edge pairing, you could somehow reduce the amount of work need after edge pairing is finished. Just a thought.

I'm not sure what Yau is, but what you said sounds to me like matching up edges in thier cycles while orientating them. I said I planned to come up with this in my last post in the 3rd edit.

Concerning using fewer moves for the solve, and still being humanly possible, it is best to solve as many things as you can at once. I already said earlier that it is possible to solve edge orientation while matching them up, but I didn't mess with the parity to much as I was figuring out the basis of the method first. When I tried to incorporate skipping the parity, I found that depending on if you got it or not, you would mess the orientation up. orientating as you match edges up uses a few more moves than orientating like you would on a 3x3 afterwards. You have to remember though, that the centers are not yet solved, and it is necessary to keep your centers turned the correct way, using more moves than orienting as you go. I did find that the most efficient way to match the turn the centers correctly while orientating the edges is to turn the front/back centers as you orientate, and turn the left/right centers as you get the top/bottom cross (the top/bottom centers are solved before this so turning them doesn't matter). I either need to find a way to bypass the parity without messing up orientation and still have it short, or find a way to determine parity before you match very many edges up at all (keeping in mind that it has to be humanly possible).

Concerning doing the edge orientation and matching circuits up at the same time, I'm not sure If I'll be able to do. I attempted and failed at coming up with a way to place corner circuits without seperating the top/bottom colors. If I couldn't figure corner circuits out, I probably won't be able to get edges into the correct circuits easily before matching them up, let alone while orientating. I would like to know if anyone knows a way to do the corner circuits, and I'll try to apply the conecept to edges. On Ryan Heise's site, he said seperating the top/bottom corners was by far the most efficient way to determine and solve the corner circuits. I, not caring about time limit, want to find a fewer moves way, and what Ryan said leads me to beleive there is a way, but it takes forever. I searched around online for it and found nothing. I think it would take fewer moves in the end to use the minimal amout of moves to circuit the corners than it would be to do the PBL idea I had, because you may do double moves to move edges while you get them on opposite colored sides. Note that matching centers up like you do the edges doesn't affect the corners because the centers are moved with slice moves.

One great way I found to save moves is to match up edges and centers at the same time. I'm not sure how to describe it through text, but you do get the top/bottom centers first. You then begin solving the other 4 centers at the same time as edges, but you usually run out of edges before you finish the centers. If you get all of the center peices matched up in pairs of 2, and line them all horazontaly, you can solve them at the same time as getting the edges on the opposite colored sides. Note that it is easier to solve the center peices at the same time getting edges on opposite colored sides if the edges are already matched up. Thus, these ideas work well together. You can oriantate edges while matching center pairs up, but again, you run into the parity problem.

EDIT: I had alot of spelling mistakes that I had to fix. When I tried putting my cursor somewhere to add a letter or take one away, what I did ovewrote what was there before rather than scooting it over. Thus, I used copy and past every time I made a mistake. I'm not sure why It is doing this. I know it wasn't doing it last time I was on.

EDIT 2: cmowla, It would be nice to see those algs. I can see them helping get past parity without messing edge orientation up. I'd like them to be shorter than the most common sigle edge flip parity alg though, or else you might as well solve the parity normally. It would also be nice if it was explainable/understandable, but I'll be fine if its not. I know there are many different parity algs out there, but I'm hoping that the move count could be shortened because you dont have to retain as much of the cube.

EDIT 3: I read some more of cuBerBruce's solution. He came at it at a much different approach. I may go back and make come at it more from his approach after I see what I can get with mine. I did come up with a much shorter way to solve the last 2 edges if one edge is oriented wrong while preserving the orientation of the rest of the edges, and the top/bottom cross. If you have 3 edges left, you can use commutators with or without a edge flipped. I think I may just use the diagnal edge swap parity for the last 2 edges when everything it oriented correctly, but I would like to get a shorter alg because you don't have to preserve as much.