solver {cubing} | R Documentation |

## Rubik's Cube Solver

### Description

Cube solvers to generate moves to a target cube state.

### Usage

```
solver(aCube, tCube, type = c("KB", "ZT", "TF"), inv = FALSE,
maxMoves = switch(type, KB = 24, ZT = 20, TF = 16), bound =
TRUE, collapse = NULL, divide = FALSE, history = FALSE,
verbose = FALSE)
```

### Arguments

`aCube` |
A cubieCube object giving the cube to be solved.
If |

`tCube` |
A cubieCube object giving the target state. If not specified, then the target state is the solved state. See Details. |

`type` |
The type of solver used. KB is Kociemba. ZT is Zemdegs-Twist. TF is Twist-Flip. |

`inv` |
If |

`maxMoves` |
The maximum number of moves allowed for the search phases of the algorithm. The search algorithm may take a long time for smaller move requirements. The default value depends on the solver. |

`bound` |
By default the |

`collapse` |
If not |

`divide` |
If |

`history` |
If |

`verbose` |
If |

### Details

The solver produces a move sequence that brings `aCube`

to either a solved
state or to the target state `tCube`

. If the target state is specified, then
`invCube(tCube) %v% aCube`

must be solvable, but the two cubes `aCube`

and `tCube`

could be unsolvable. See the help file on `invCube`

for
more details.

The KB algorithm is a 2-phase search. The ZT algorithm is similar but allows for
twisting corners at the end to solve the corner orientation. The TF algorithm
allows for twisting corners and flipping edges at the end to solve both corner and
edge orientation. The twisting and flipping procedures are given as attributes in
the returned object. If `inv`

is `TRUE`

, then they need to be performed
at the start from the solved (or target) state.

The ZT and TF solvers may not produce a smaller move count than KB because the aim of
the solver is to return any solution that consists of `maxMoves`

moves or less.
If smaller move counts are required then `maxMoves`

should be specified.

These solvers are lightweight in the sense that they use small look-up tables (move
tables and prune tables). If `maxMoves`

is small then it can take a few seconds
to find a solution.

The look-up tables for a solver are silently loaded into memory the first time the solver is used. The tables are hidden objects that are not visible to the user. If you wish to ensure that all tables are already loaded into memory (for example, if you want to do timing comparisons), then you can run each type of solver once, using any cube other than the solved (or target) state.

The solvers will never produce two moves in a row on the same face, but may produce three (or even four) moves in a row on opposite faces if this coincides with the break between the two search phases. They cannot produce three moves in a row on opposite faces within the same search phase. This behaviour is a design choice in order to minimize second phase solutions that are rejected due to move sequences across the phase break.

### Value

A character vector of moves, or a character string if `collapse`

is not `NULL`

.
For ZT the vector (or string) has a twist attribute. For TF the vector (or string) has
twist and flip attributes.

If history is `TRUE`

, then a list of length two is returned where the second element
is a matrix that provides information on the history of the search algorithm.

### See Also

`getMovesCube`

, `invCube`

, `invMoves`

,
`is.solvable`

, `scramble`

### Examples

```
aCube <- getCubieCube("EasyCheckerboard")
## Not run: plot(aCube)
## Not run: plot3D(aCube)
mvs <- solver(aCube, type = "KB")
is.solved(aCube %v% getMovesCube(mvs))
```

*cubing*version 1.0-5 Index]