blocks|key|4453412|text|这个ACM+Paper描述了它用来表示魔方的几种替代方法，并对它们进行了比较。遗憾的是，我没有获取全文的帐户，但描述中写道：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4453413|4453414|提出并比较了魔方的七种可选表示:3位整数的3x3x3数组；6x3x3文字数组；5x12文字矩阵；11x11稀疏文字矩阵；54元素向量；4维数组；以及3x3x3嵌套数组。APL函数用于方向移动和四分之一转弯，以及几个用于求解立方体的有用工具。|blockquote|4453415|4453416|此外，这个RubiksCube.java文件包含一个非常干净的表示，以及用于旋转部分的相关代码(如果您正在寻找实际的代码)。它使用一个单元格和一个面数组。|4453417|entityMap|0|LINK|mutability|MUTABLE|url|http://portal.acm.org/citation.cfm?id=801107&coll=portal&dl=ACM|1|http://symbolaris.com/orbital/Orbital-doc/examples/Algorithms/RubiksCube.java^0|2|9|0|0|0|0|0|5|F|1|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|K|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]]]

This <a href="http://portal.acm.org/citation.cfm?id=801107&amp;coll=portal&amp;dl=ACM" rel="noreferrer">ACM Paper</a> describes several alternative ways that it has used to represent a rubik's cube and compares them against eachother. Sadly, I don't have an account to get the full text but the description states:

<blockquote>
 Seven alternative representations of Rubik's Cube are presented and compared: a 3-by-3-by-3 array of 3-digit integers; a 6-by-3-by-3 array of literals; a 5-by-12 literal matrix; an ll-by-ll sparse literal matrix; a 54-element vector; a 4-dimension array; and a 3-by-3-by-3 nested array. APL functions are given for orientation moves and quarter-turns plus several useful tools for solving the cube. 
</blockquote>

Also, this <a href="http://symbolaris.com/orbital/Orbital-doc/examples/Algorithms/RubiksCube.java" rel="noreferrer">RubiksCube.java</a> file contains a pretty clean representation along with the relevant code for rotating the sections (if you are looking for actual code). It uses a cell and faces array.

blocks|key|2340534|text|一种方法是专注于视觉外观。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2340535|一个立方体有六个面，每个面是一个三乘三的正方形阵列。所以|2340536|Color[][][]+rubik+=+new+Color[6][3][3];|code-block|syntax|javascript|2340537|然后，每一步都是一种方法，它会排列一组特定的彩色方块。|2340538|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

One way would be to focus on the visual appearance.

A cube has six faces and each face is a three-by-three array of squares. So

<pre><code>Color[][][] rubik = new Color[6][3][3];
</code></pre>

Then each move is a method that permutes a specific set of colored squares.

blocks|key|4453499|text|避免优化；使其面向对象。我使用的伪代码类大纲是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4453500|class+Square
++++%2B+name+:+string
++++%2B+accronym+:+string

class+Row
++++%2B+left_square+:+square
++++%2B+center_square+:+square
++++%2B+right_square+:+square

class+Face
++++%2B+top_row+:+list+of+3+square
++++%2B+center_row+:+list+of+3+square
++++%2B+bottom_row+:+list+of+3+square

++++%2B+rotate(counter_clockwise+:+boolean)+:+nothing

class+Cube
++++%2B+back_face+:+face
++++%2B+left_face+:+face
++++%2B+top_face+:+face
++++%2B+right_face+:+face
++++%2B+front_face+:+face
++++%2B+bottom_face+:+face

++++-+rotate_face(cube_face+:+face,+counter_clockwise+:+boolean)+:+nothing|code-block|syntax|javascript|4453501|内存使用量如此之小，处理如此之少，以至于优化是完全不必要的，特别是当你牺牲代码可用性的时候。|4453502|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Eschew optimisation; make it object-oriented. A pseudocode class outline I've used is:

<pre><code>class Square
 + name : string
 + accronym : string

class Row
 + left_square : square
 + center_square : square
 + right_square : square

class Face
 + top_row : list of 3 square
 + center_row : list of 3 square
 + bottom_row : list of 3 square

 + rotate(counter_clockwise : boolean) : nothing

class Cube
 + back_face : face
 + left_face : face
 + top_face : face
 + right_face : face
 + front_face : face
 + bottom_face : face

 - rotate_face(cube_face : face, counter_clockwise : boolean) : nothing
</code></pre>

The amount of memory used is so small and processing so minimal that optimisation is totally unnecessary, especially when you sacrifice code usability.

blocks|key|2340748|text|简而言之，这取决于你如何解决这个立方体。如果您的求解器将使用人工方法，如逐层方法或Fridrich方法，那么底层数据结构将不会有太大区别。即使在最慢的编程语言中，计算机也可以用人类的方法在可以忽略的时间(不到一秒)内求解一个立方体。但是，如果要使用计算量更大的方法来求解立方体，例如Thistlethwaite的52-move算法、Reid的29-move算法或Korf的20-move算法，那么数据结构和编程语言就非常重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2340749|我实现了一个魔方程序，该程序使用OpenGL渲染魔方，它内置了两种不同类型的求解器(Thistlethwaite和Korf)。求解器必须生成数十亿次移动，并将每个立方体状态进行数十亿次比较，因此底层结构必须快速。我尝试了以下结构：|2340750|2340751|字符的三维数组，6x3x3。脸部的颜色类似于cubeSIDECOL的索引。这很直观，但速度很慢。|ordered-list-item|2340752|由54个字符组成的单个数组。这比(1)更快，并且行和步长是手动计算的(微不足道)。|2340753|6+64位整数。此方法本质上是一个位板，并且比方法(1)和(2)快得多。扭曲可以使用逐位操作，面部比较可以使用掩码和64位整数比较。|2340754|一个角立方体数组和一个单独的边缘立方体数组。每个数组的元素都包含一个立方体索引(边0+-11；角0-7+)和方向(边0或1；角0、1或2)。当求解程序涉及模式数据库时，这是理想的选择。|2340755|2340756|在上面的方法(3)上扩展，立方体的每个面由9个贴纸组成，但中心是固定的，所以只需要存储8个。有6种颜色，所以每种颜色适合一个字节。给定这些颜色定义：|2340757|enum+class+COLOR+:+uchar+{WHITE,+GREEN,+RED,+BLUE,+ORANGE,+YELLOW};|code-block|syntax|javascript|2340758|面孔可能如下所示，存储在单个64位整数中：|2340759|00000000+00000001+00000010+00000011+00000100+00000101+00000000+00000001|2340760|它被解码为：|2340761|WGR
G+B
WYO|2340762|使用这种结构的一个优点是，可以使用rolq和rorq位运算符来移动面。滚动16位可实现90度旋转；滚动32位可实现180度旋转。相邻的部分需要手动维护--即旋转顶面后，前、左、后和右面的顶层也需要移动。以这种方式转脸真的很快。例如，滚动|offset|length|style|CODE|2340763|00000000+00000001+00000010+00000011+00000100+00000101+00000000+00000001|2340764|乘以16位可产生|2340765|00000000+00000001+00000000+00000001+00000010+00000011+00000100+00000101|2340766|解码后，看起来是这样的：|2340767|WGW
Y+G
OBR|2340768|另一个优点是，在某些情况下，可以使用一些巧妙的位掩码和标准整数比较来比较多维数据集状态。对于求解器来说，这可能是一个相当大的加速。|2340769|不管怎么说，我的实现是在github上实现的：https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0请参阅Model/RubiksCubeModel.{h,cpp}。|2340770|在上面方法(4)的基础上扩展，一些用于编程求解魔方的算法使用迭代加深深度优先搜索A*，使用模式数据库作为启发式。例如，Korf的算法利用了三个模式数据库:一个存储了8个角立方体的索引和方向；一个存储了12个边块中6个的索引和方向；最后一个存储了其他6个边的索引和方向。使用模式数据库时，一种快速的方法是将多维数据集存储为一组索引和方向。|2340771|任意定义一个约定，边缘立方体可以被索引如下。|2340772|0++1++2++3++4++5++6++7++8++9++10+11+//+Index.
UB+UR+UF+UL+FR+FL+BL+BR+DF+DL+DB+DR+//+Position+(up-back,+...,+down-right).
RY+RG+RW+RB+WG+WB+YB+YG+OW+OB+OY+OG+//+Colors+(red-yellow,+...,+orange-green).|2340773|因此，红黄边立方体的索引为0，白绿边立方体的索引为4。同样，角立方体的索引可能如下所示：|2340774|0+++1+++2+++3+++4+++5+++6+++7
ULB+URB+URF+ULF+DLF+DLB+DRB+DRF
RBY+RGY+RGW+RBW+OBW+OBY+OGY+OGW|2340775|因此，红蓝黄三色角立方体的索引为0，而橙绿黄三色角立方体的索引为6。|2340776|每个立方体的方向也需要保持不变。边段可以是两个方向之一(定向或翻转)，而角段可以是三个不同的方向(定向、旋转一次或旋转两次)。关于块方向的更多细节可以在这里找到：http://cube.crider.co.uk/zz.php?p=eoline#eo_detection对于这个模型，旋转面意味着更新索引和方向。这种表示是最困难的，因为对于一个人来说(至少对我来说)很难看到一大堆索引和方向数字并验证它们的正确性。也就是说，该模型比使用上面描述的其他模型之一动态计算索引和方向的速度要快得多，因此它是使用模式数据库时的最佳选择。你可以在这里看到这个模型的一个实现：https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model+(参见RubiksCubeIndexModel.{h,cpp})。|2340777|如前所述，该程序还渲染立方体。我对这部分使用了不同的结构。我定义了一个"cubie“类，它是一个六个正方形，分别有1、2或3个颜色面，分别用于中心、边缘和角部。魔方是由26个魔方组成的。使用四元数旋转面。多维数据集和多维数据集的代码如下：https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model/WorldObject|2340778|如果你对我的魔方解算器程序感兴趣，在YouTube上有一个高级概述视频：https://www.youtube.com/watch?v=ZtlMkzix7Bw&feature=youtu.be我还有一个更广泛的关于在Medium上编程求解魔方的文章。|2340779|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0|1|http://cube.crider.co.uk/zz.php?p=eoline#eo_detection|2|https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model|3|https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model/WorldObject|4|https://www.youtube.com/watch?v=ZtlMkzix7Bw&feature=youtu.be|5|https://medium.com/@benjamin.botto/implementing-an-optimal-rubiks-cube-solver-using-korf-s-algorithm-bf750b332cf9^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|H|4|M|4|0|0|0|0|0|0|0|2C|T|N|1M|0|0|0|0|0|0|0|0|9P|S|29|1H|1|7T|1S|2|0|3B|24|3|0|10|1O|4|30|6|5|0^^$0|@$1|2|3|4|5|6|7|2N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2O|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|2Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|2R|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|2S|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|2T|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|2U|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|2V|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|2W|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|2X|8|@]|9|@]|A|$]]|$1|X|3|Y|5|S|7|2Y|8|@]|9|@]|A|$T|U]]|$1|Z|3|10|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|11|3|12|5|S|7|30|8|@]|9|@]|A|$T|U]]|$1|13|3|14|5|6|7|31|8|@$15|32|16|33|17|18]|$15|34|16|35|17|18]]|9|@]|A|$]]|$1|19|3|1A|5|S|7|36|8|@]|9|@]|A|$T|U]]|$1|1B|3|1C|5|6|7|37|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|S|7|38|8|@]|9|@]|A|$T|U]]|$1|1F|3|1G|5|6|7|39|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|S|7|3A|8|@]|9|@]|A|$T|U]]|$1|1J|3|1K|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3C|8|@$15|3D|16|3E|17|18]]|9|@$15|3F|16|3G|1|3H]]|A|$]]|$1|1N|3|1O|5|6|7|3I|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|6|7|3J|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|S|7|3K|8|@]|9|@]|A|$T|U]]|$1|1T|3|1U|5|6|7|3L|8|@]|9|@]|A|$]]|$1|1V|3|1W|5|S|7|3M|8|@]|9|@]|A|$T|U]]|$1|1X|3|1Y|5|6|7|3N|8|@]|9|@]|A|$]]|$1|1Z|3|20|5|6|7|3O|8|@$15|3P|16|3Q|17|18]]|9|@$15|3R|16|3S|1|3T]|$15|3U|16|3V|1|3W]]|A|$]]|$1|21|3|22|5|6|7|3X|8|@]|9|@$15|3Y|16|3Z|1|40]]|A|$]]|$1|23|3|24|5|6|7|41|8|@]|9|@$15|42|16|43|1|44]|$15|45|16|46|1|47]]|A|$]]|$1|25|3|-4|5|6|7|48|8|@]|9|@]|A|$]]]|26|$27|$5|28|29|2A|A|$2B|2C]]|2D|$5|28|29|2A|A|$2B|2E]]|2F|$5|28|29|2A|A|$2B|2G]]|2H|$5|28|29|2A|A|$2B|2I]]|2J|$5|28|29|2A|A|$2B|2K]]|2L|$5|28|29|2A|A|$2B|2M]]]]

The short answer is that it depends on how you're going to solve the cube. If your solver is going to use a human method like the layer-by-layer approach or the Fridrich method then the underlying data structure won't make much of a difference. A computer can solve a cube using a human method in negligible time (well under a second) even in the slowest of programming languages. But if you are going to solve the cube using a more computationally intensive method such as Thistlethwaite's 52-move algorithm, Reid's 29-move algorithm, or Korf's 20-move algorithm, then the data structure and programming language are of utmost importance.

I implemented a Rubik's Cube program that renders the cube using OpenGL, and it has two different types of solvers built in (Thistlethwaite and Korf). The solver has to generate billions of moves and compare each cube state billions of times, so the underlying structure has to be fast. I tried the following structures:

<ol>
<li>A three-dimensional array of chars, 6x3x3. The color of a face is indexed like cube[SIDE][ROW][COL]. This was intuitive, but slow.</li>
<li>A single array of 54 chars. This is faster than (1), and the row and stride are calculated manually (trivial).</li>
<li>6 64-bit integers. This method is essentially a bitboard, and is significantly faster than methods (1) and (2). Twisting can be done using bit-wise operations, and face comparisons can be done using masks and 64-bit integer comparison.</li>
<li>An array of corner cubies and a separate array of edge cubies. The elements of each array contain a cubie index (0-11 for edges; 0-7 for corners) and an orientation (0 or 1 for edges; 0, 1, or 2 for corners). This is ideal when your solver involves pattern databases.</li>
</ol>

Expanding on method (3) above, each face of the cube is made up of 9 stickers, but the center is stationary so only 8 need to be stored. And there are 6 colors, so each color fits in a byte. Given these color definitions:

<pre><code>enum class COLOR : uchar {WHITE, GREEN, RED, BLUE, ORANGE, YELLOW};
</code></pre>

A face might look like this, stored in a single 64-bit integer:

<pre><code>00000000 00000001 00000010 00000011 00000100 00000101 00000000 00000001
</code></pre>

Which is decoded as:

<pre><code>WGR
G B
WYO
</code></pre>

An advantage of using this structure is that the <code>rolq</code> and <code>rorq</code> bit-wise operators can be used to move a face. Rolling by 16 bits effects a 90-degree rotation; rolling by 32 bits gives a 180-degree turn. The adjacent pieces need to be up-kept manually--i.e. after rotating the top face, the top layer of the front, left, back, and right faces need to be moved, too. Turning faces in this manner is really fast. For example, rolling

<pre><code>00000000 00000001 00000010 00000011 00000100 00000101 00000000 00000001
</code></pre>

by 16 bits yields

<pre><code>00000000 00000001 00000000 00000001 00000010 00000011 00000100 00000101
</code></pre>

Decoded, that looks like this:

<pre><code>WGW
Y G
OBR
</code></pre>

Another advantage is that comparing cube states can in some instances be done using some clever bit masks and standard integer comparisons. That can be a pretty big speed-up for a solver.

Anyway, my implementation is on github: <a href="https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0" rel="noreferrer">https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0</a> See <code>Model/RubiksCubeModel.{h,cpp}</code>.

Expanding on method (4) above, some of the algorithms for programmatically solving the Rubik's Cube use an iterative deepening depth-first search with A*, using pattern databases as a heuristic. For example, Korf's algorithm utilizes three pattern databases: one stores the index and orientation of the 8 corner cubies; one stores the index and orientation of 6 of the 12 edge pieces; the last stores the index and orientation of the other 6 edges. When using pattern databases, a fast approach is to store the cube as a set of indexes and orientations.

Arbitrarily defining a convention, the edge cubies could be indexed as follows.

<pre><code>0 1 2 3 4 5 6 7 8 9 10 11 // Index.
UB UR UF UL FR FL BL BR DF DL DB DR // Position (up-back, ..., down-right).
RY RG RW RB WG WB YB YG OW OB OY OG // Colors (red-yellow, ..., orange-green).
</code></pre>

So the red-yellow edge cubie is at index 0, and the white-green edge cubie is at index 4. Likewise, the corner cubies might be indexed like so:

<pre><code>0 1 2 3 4 5 6 7
ULB URB URF ULF DLF DLB DRB DRF
RBY RGY RGW RBW OBW OBY OGY OGW
</code></pre>

So the red-blue-yellow corner cubie is at index 0, and the orange-green-yellow corner cubie is at index 6.

The orientation of each cubie needs to be kept as well. An edge piece can be in one of two orientations (oriented or flipped), while a corner piece can be in three different orientations (oriented, rotated once, or rotated twice). More details about the orientation of pieces can be found here: <a href="http://cube.crider.co.uk/zz.php?p=eoline#eo_detection" rel="noreferrer">http://cube.crider.co.uk/zz.php?p=eoline#eo_detection</a> With this model, rotating a face means updating indexes and orientations. This representation is the most difficult because it's hard for a human (for me at least) to look at a big blob of index and orientation numbers and verify their correctness. That being said, this model is significantly faster than dynamically calculating indexes and orientations using one of the other models described above, and so it's the best choice when using pattern databases. You can seen an implementation of this model here: <a href="https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model" rel="noreferrer">https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model</a> (see <code>RubiksCubeIndexModel.{h,cpp}</code>).

As mentioned, the program also renders the cube. I used a different structure for that part. I defined a "cubie" class, which is a six squares with 1, 2, or 3 colored faces for center, edge, and corner pieces, respectively. The Rubik's Cube is then composed of 26 cubies. The faces are rotated using quaternions. The code for the cubies and cube is here: <a href="https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model/WorldObject" rel="noreferrer">https://github.com/benbotto/rubiks-cube-cracker/tree/2.2.0/Model/WorldObject</a>

If you're interested in my Rubik's Cube solver program, there's a high-level overview video on YouTube: <a href="https://www.youtube.com/watch?v=ZtlMkzix7Bw&amp;feature=youtu.be" rel="noreferrer">https://www.youtube.com/watch?v=ZtlMkzix7Bw&amp;feature=youtu.be</a> I also have a more extensive write-up on solving the Rubik's Cube programmatically on <a href="https://medium.com/@benjamin.botto/implementing-an-optimal-rubiks-cube-solver-using-korf-s-algorithm-bf750b332cf9" rel="noreferrer">Medium</a>.

blocks|key|2340648|text|软件"Cube+Explorer“使用了一种有趣的方法来表示立方体。使用许多巧妙的数学方法，该方法可以仅使用5个整数来表示立方体。作者在他的website上解释了他的程序背后的数学原理。根据作者的说法，这种表示适合于实现快速求解器。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2340649|entityMap|0|LINK|mutability|MUTABLE|url|http://kociemba.org/cube.htm^0|1Y|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

An interesting method to represent the cube is used by the software "Cube Explorer". Using a lot of clever maths that method can represent the cube using only 5 integers. The author explains the maths behind his program on his <a href="http://kociemba.org/cube.htm" rel="noreferrer">website</a>. According to the author the representation is suited to implement fast solvers.

blocks|key|5869052|text|有很多方法可以做到这一点。有些方法比其他方法更有效地使用内存。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5869053|我见过人们使用3x3x3的长方体对象数组，其中长方体对象需要存储颜色信息(是的，中心对象从未使用过)。我见过人们使用6个数组，每个数组都是一个3+x+3的长方体数组。我已经看到了一个3+x+18的长方体阵列。有很多可能性。|5869054|可能更大的问题是如何表示各种转换。旋转物理立方体的单个面(所有立方体移动本质上都是单个面的旋转)必须通过交换许多立方体对象来表示。|5869055|您的选择应该对您正在编写的任何应用程序都有意义。可能只是渲染了立方体。可能是因为没有UI。你可能在解这个立方体。|5869056|我会选择3+x+18的数组。|5869057|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

There are many ways to do this. Some ways are make more efficient use of memory than others.

I have seen people use a 3 x 3 x 3 array of cuboid objects, where the cuboid object needs to store color information (and yes, that center object is never used). I have seen people use 6 arrays, each of which is a 3 x 3 array of cuboids. I have seen a 3 x 18 array of cuboids. There are many possibilities.

Probably a bigger concern is how to represent the various transforms. Rotating a single face of a physical cube (all cube moves are essentially rotations of a single face) would have to be represented by swapping around a lot of cuboid objects.

Your choice should be one that makes sense for whatever application you are writing. It may be that you are only rendering the cube. It may be that there is no UI. You may be solving the cube.

I would choose the 3 x 18 array.

blocks|key|1790953|text|有20个立方体很重要。因此，一种方法是将其作为20个字符串数组。字符串将包含2到3个表示颜色的字符。任何一次移动都会影响7个立方体。因此，您只需要为六个边的每一个重新映射器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1790954|注意:此解决方案无法记住白色中心上的徽标贴纸的方向。|1790955|顺便说一句，我曾帮助某人做过一次软件魔方，大概在15年前，但我不记得我们是如何表示它的。|1790956|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are 20 cubies that matter. So one way to do it is as an array of 20 strings. The strings would hold 2 or 3 characters indicating the colors. Any single move affects 7 of the cubies. So you just need a remapper for each of the six sides.

Note: This solution doesn't manage to remember the orientation of the logo sticker that's on the white center.

By the way, I helped someone do a software Rubik's cube once, maybe 15 years ago, but I can't remember how we represented it.

blocks|key|5869113|text|你可以把这个立方体想象成三个垂直的循环链表，它们与三个水平链表相交。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5869114|每当旋转立方体的某一行时，您只需旋转相应的指针即可。|5869115|它看起来像这样：|5869116|struct+cubeLinkedListNode+{
++++cubedLinkedListNode*+nextVertical;
++++cubedLinkedListNode*+lastVertical;
++++cubedLinkedListNode*+nextHorizontal;
++++cubedLinkedListNode*+lastHorizontal;
++++enum+color;
}|code-block|syntax|javascript|5869117|你可能实际上并不需要2个‘last’指针。|5869118|我用C实现了这一点，但它也可以用Java或C#实现，只需使用cubeLinkedListNode的一个简单类，每个类都包含对其他节点的引用。|5869119|记住，有六个相互关联的循环链表。3垂直3水平。|5869120|对于每一次旋转，您只需循环遍历相应的循环链表，依次移动旋转圆的链接以及连接的圆。|5869121|就像这样，至少...|5869122|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

You could imagine the cube as three vertical circular linked lists, which intersect three horizontal linked lists. 

Whenever a certain row of the cube is rotated you would just rotate the corresponding pointers. 

It would look like this:

<pre><code>struct cubeLinkedListNode {
 cubedLinkedListNode* nextVertical;
 cubedLinkedListNode* lastVertical;
 cubedLinkedListNode* nextHorizontal;
 cubedLinkedListNode* lastHorizontal;
 enum color;
}
</code></pre>

You might not actually need the 2 'last'-pointers.

[ I did this with C, but it could be done in Java or C# just using a simple class for cubeLinkedListNode, with each class holding references to other nodes. ]

Remember there are six interlocking circular linked lists. 3 vertical 3 horizontal.

For each rotation you would just loop through the corresponding circular linked list sequentially shifting the links of the rotating circle, as well as the connecting circles.

Something like that, at least...

blocks|key|1791075|text|最短的表示如下所示：codepen.io/Omelyan/pen/BKmedK|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1791076|立方体在一维数组(+54个元素的向量)中展开。几行旋转函数交换贴纸并基于立方体的对称性。这是一个完整的C语言工作模型，我在2007年还是个学生的时候做的：|1791077|const+byte+//+symmetry
++M[]+=+{2,4,3,5},
++I[]+=+{2,0,4,6};

byte+cube[55];+//+0,0,0,0,0,0,0,0,0,+1,1,1,1,1,1,1,1,1,+...+need+to+be+filled+first

#define+m9(f,+m)+(m6(f,+m)*9)

byte+m6(byte+f,+byte+m)+{return+((f&~1)%2BM[m%2B(f&1)*(3-2*m)])%256;}

void+swap(byte+a,+byte+b,+byte+n)+{
++while+(n--)+{byte+t=cube[a%2Bn];+cube[a%2Bn]=cube[b%2Bn];+cube[b%2Bn]=t;}
}

void+rotate(byte+f,+byte+a)+{+//+where+f+is+face,+and+a+is+number+of+90+degree+turns
++int+c=m9(f,+3),+i;
++swap(c,+c%2B8,+1);
++while+(a--%254)+for+(i=2;+i>=0;+--i)
++++swap(m9(f,+i)+%2B+I[i],+m9(f,+i%2B1)+%2B+I[i%2B1],+3),
++++swap(f*9%2Bi*2,+f*9%2Bi*2%2B2,+2);
++swap(c,+c%2B8,+1);
}|code-block|syntax|javascript|1791078|entityMap|0|LINK|mutability|MUTABLE|url|https://codepen.io/Omelyan/pen/BKmedK^0|A|T|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|C|$I|J]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

The shortest representation is something like this one: <a href="https://codepen.io/Omelyan/pen/BKmedK" rel="nofollow noreferrer">codepen.io/Omelyan/pen/BKmedK</a>
The cube is unwrapped in 1D array (vector of 54 elements). A few-line rotation function swaps stickers and based on the cube's symmetry. Here's complete working model in C, I made it in 2007 when was a student:
<pre><code>const byte // symmetry
 M[] = {2,4,3,5},
 I[] = {2,0,4,6};

byte cube[55]; // 0,0,0,0,0,0,0,0,0, 1,1,1,1,1,1,1,1,1, ... need to be filled first

#define m9(f, m) (m6(f, m)*9)

byte m6(byte f, byte m) {return ((f&amp;~1)+M[m+(f&amp;1)*(3-2*m)])%6;}

void swap(byte a, byte b, byte n) {
 while (n--) {byte t=cube[a+n]; cube[a+n]=cube[b+n]; cube[b+n]=t;}
}

void rotate(byte f, byte a) { // where f is face, and a is number of 90 degree turns
 int c=m9(f, 3), i;
 swap(c, c+8, 1);
 while (a--%4) for (i=2; i&gt;=0; --i)
 swap(m9(f, i) + I[i], m9(f, i+1) + I[i+1], 3),
 swap(f*9+i*2, f*9+i*2+2, 2);
 swap(c, c+8, 1);
}
</code></pre>

blocks|key|2340618|text|其他很好地解决了描述物理立方体的问题，但是关于立方体的状态...我会尝试使用一个矢量变换数组来描述立方体的变化。这样，您可以在进行更改时保留rubiks立方体的历史。我想知道你是否可以将向量乘成一个变换矩阵，以找到最简单的解？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2340619|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The others well addressed describing the physical cube, but regarding the state of the cube... I would try using an array of vector transformations to describe the changes of the cube. That way you could keep the history of the rubiks cube as changes are made. And I wonder if you could multiply the vectors into a transformation matrix to find the simplest solution?

blocks|key|2340637|text|作为48个可以移动的面的排列。基本旋转也是排列，排列可以组合，它们形成一个组。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2340638|在程序中，这样的排列将由一个包含数字0到47的48个元素的数组来表示。对应于数字的颜色是固定的，因此可以根据排列计算视觉表示，反之亦然。|2340639|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

As a permutation of the 48 faces which can move. The basic rotations are also permutations, and permutations can be composed, they form a group.

In a program such a permutation would be represented by an array of 48 elements containing numbers 0 to 47. The colors corresponding to the numbers are fixed, so a visual representation can be computed from the permutation, and vice versa.

blocks|key|2340827|text|我发现将状态存储为从面外的立方体中心坐标到颜色的映射是非常有用的。例如，前面-右上角立方体的上表面是state[1,+-1,+2]。因此，只需对索引应用旋转即可完成移动。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2340828|你可以在这里看到我用它写的一个简单的模拟器：https://github.com/noamraph/cube|2340829|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/noamraph/cube^0|1E|F|0|M|W|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@]|D|@$9|T|A|U|1|V]]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

I found it very useful to store the state as a mapping from the coordinates of the center of the cubelet outside the face to the color. So, for example, the upper face of the front-top-right cubelet is <code>state[1, -1, 2]</code>. So moves are done by just applying rotations to the indices.
You can see a simple simulator I wrote using it here: <a href="https://github.com/noamraph/cube" rel="nofollow noreferrer">https://github.com/noamraph/cube</a>

If you were developing software to solve a Rubik's Cube, how would you represent the cube?

How would you represent a Rubik's Cube in code?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如果您正在开发软件来求解魔方，您将如何表示魔方？

问你将如何在代码中表示魔方？
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你将如何在代码中表示魔方？EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你将如何在代码中表示魔方？
EN