Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

baby_fto definition is missing Bv move #99

Open
lgarron opened this issue Feb 1, 2025 · 1 comment
Open

baby_fto definition is missing Bv move #99

lgarron opened this issue Feb 1, 2025 · 1 comment
Labels
bug Something isn't working

Comments

@lgarron
Copy link
Member

lgarron commented Feb 1, 2025

./script/cubing-def baby_fto doesn't produce it, I'm not sure why yet. (Twizzle Editor supports it.)

@lgarron lgarron added the bug Something isn't working label Feb 1, 2025
@rokicki
Copy link
Collaborator

rokicki commented Feb 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants