Let's talk about turn metrics

[Andrew Farkas]

Hello, hypercubers!

Historically, twist count has been determined by the number of clicks in MC4D. This metric has a few quirks:

- 180-degree face twists count as two moves but all other twists of a single cell can count as one.

- Noncontiguous slice twists that would be extremely awkward to perform on a physical 3D puzzle count as just one move.

- Rotating all layers at once counts as a twist, even though the puzzle does not change state.

Luna Harran and I came up with the following eight twist metrics, all of which are available in Hyperspeedcube:

- Axial Turn Metric (ATM)

    - Consecutive twists of the same axis are combined, even with different layers.

    - Whole-puzzle rotations are not counted.

- Execution Turn Metric (ETM)

    - Twists are counted as they are executed, including whole-puzzle rotations.

- Slice Turn Metric (STM, the default in Hyperspeedcube)

    - Whole-puzzle rotations are not counted.

    - Slice twists count as one move.

    - Consecutive twists of the same axis and layers are combined.

- Block Turn Metric (BTM)

    - Whole-puzzle rotations are not counted.

    - Noncontiguous slice twists are split into contiguous slice twists.

    - Consecutive twists of the same axis and layers are combined.

- Outer Block Turn Metric (OBTM)

    - Whole-puzzle rotations are not counted.

    - Noncontiguous slice twists are split into contiguous outer-block twists.

    - Consecutive twists of the same axis and layers are combined.

- Quarter Turn Metric variants (QSTM, BTM, OBTM)

    - Same as STM, BTM, and OBTM respectively, except that twists are first split into 90-degree face twists.

The metric used by MC4D can be classified as ETM, with the limitation that MC4D has no way to execute 180-degree face twists in a single move. (Hyperspeedcube does, using custom keybindings or Tools → Puzzle controls.) Choosing any of these as the official standard for fewest-moves challenge will require re-scoring existing solves for fairness. Ignoring QTM variants, below are the results of re-scoring the shortest solutions to 2^4, 3^4, and 5^4 by opening the log files in Hyperspeedcube.

- Daniel Kwan's 2^4 solution

    - ATM: 37

    - ETM: 46

    - STM: 39 (-7 compared to ETM)

    - BTM & OBTM are identical to STM for 2^n

- Charles Doan's 3^4 solution

    - ATM: 184

    - ETM: 191

    - STM/BTM: 188 (-3 compared to ETM)

    - OBTM: 191

- Andrey Astrelin's 5^4 solution

    - ATM: 1556

    - ETM: 1981

    - STM: 1850 (-131 compared to ETM)

    - BTM: 1860

    - OBTM: 2848

These ETM values are the same as what MC4D says, but these solves could easily be copied move-for-move in Hyperspeedcube using proper 180-degree face twists to reach the STM numbers. Incidentally, it should always be possible to match ATM and STM on 2^4, so Daniel Kwan's solution could be shortened to 37 STM.

I propose that Slice Turn Metric be considered the default, since I believe it is well-defined for all twisty puzzles, generally scores the closest to MC4D's metric, is backwards-compatible with 3D Slice Turn Metric, and is "fair" regardless of input method. For example, the default keyboard bindings only provide access to 90-degree face twists, but it's very fast to execute several in quick succession to produce other twists.

What are your thoughts?

--

"Machines take me by surprise with great frequency." - Alan Turing

[Melinda Green]

On 9/2/2022 10:38 PM, Andrew Farkas wrote:

I propose that Slice Turn Metric be considered the default, since I believe it is well-defined for all twisty puzzles, generally scores the closest to MC4D's metric, is backwards-compatible with 3D Slice Turn Metric, and is "fair" regardless of input method. For example, the default keyboard bindings only provide access to 90-degree face twists, but it's very fast to execute several in quick succession to produce other twists.

What are your thoughts?

If I understand correctly, I agree, as this was part of a change that I've long been wanting to make which is the essence of issue #36 in the GitHub issue tracker. As mentioned on that issue, a good case to consider is the "onehundredagonal" puzzle. To twist one of the onehundredagonal pieces half way around currently takes 50 moves which seems kind of absurd. Here was my UI proposal from that time:

"Just thinking blue-sky here, I can imagine not a single click but perhaps a way  to continuously drag a face around the same way we currently drag the whole puzzle. (By adding the Alt modifier, perhaps?) Imagine that whenever the orientation of that face comes near a legal twist position, that it snaps to that position such that it  stays there if the user releases the mouse. Whenever they release the mouse it should fall into the closest-fit position. This would cost the user one twist of course, though it would also be cool to let them perform as many of these twists as they like on a single face and call it one twist."

This goes beyond what you have done with Hyperspeedcube, but I think it will be helpful to keep in mind as a possible end goal for both or all simulators. In other words, I like where this is going and propose trying not to make decisions that might rule out this goal.

-Melinda