You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a good point. For all puzzles, the rotations produced are not redundant on an axis; for every axis, we produce exactly one rotation move. So for instance on the 333, we produce Rv (which we call x), but not Lv (which is just Rv').
For twizzle editor and twizzle explorer, the move swizzler classes know how to generate moves that "make sense" according to SiGN into actual permutations from the move permutations that are given, so all those moves (and many others, such as 22-27U on a 99x99x99) work fine, without having to explicitly generate them beforehand (which is entirely impractical for a 99x99x99).
This can be annoying when using pg-generated output (ksolve, gap) outside of twizzle editor and twizzle explorer. One fix may be to stand up a "move expander" specification that can be separately implemented in Rust and/or C++ to do the same thing that happens in the Javascript.
./script/cubing-def baby_fto
doesn't produce it, I'm not sure why yet. (Twizzle Editor supports it.)The text was updated successfully, but these errors were encountered: