-
Notifications
You must be signed in to change notification settings - Fork 9
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
Orders for puzzles with identical pieces #49
Comments
I'm not so sure this is the "widely-accepted definition", although I see
cases where it can be useful. One might consider what twsearch does
now as "pure order" and what you are asking for is "impure from solved"
but of course there can also be impure from any arbitrary position.
Is this of immediate utility? It would be pretty trivial to add an impure
order option.
…On Wed, Feb 21, 2024 at 5:21 AM Marius0509 ***@***.***> wrote:
I think the widely accepted definition of the order of a scramble is how
many times you need to execute it from the solved state in order for the
cube to come back to the solved state. So, I don't think -o and --ordertree
should output orders for the supercube unless --distinguishall is
mentioned. If doing the lcm of every cycle doesn't work for puzzles with
identical pieces, then an alternative approach is doing the lcm of every
set's order.
For example, I think the scramble "R U' R U R U R U' R' U' R2" should have
the order 3 on 4x4 (not 12), just like on the 3x3 cube.
—
Reply to this email directly, view it on GitHub
<#49>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS6JE3PYIQVMWAKOIFTYUXYHDAVCNFSM6AAAAABDTBNOUGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DMNZUGU4TSNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Considering the old version calculated impure orders, I think this should also be a feature in the current version. It also wouldn't remove any existent feature, the pure order can still be obtained using --distinguishall. |
Ahh, you raise a good point. Two, in fact. But I don't like the "default"
(no distinguish-all) to calculate
"impure" orders as I think that's a special case and dependent on what
"solved" position you work
from. I considered the old behavior a bug.
I propose adding a "--impure" option that affects this (and possibly other
functionality). The
implementation will likely calculate the pure order, then check dividing
this by the various prime
factors to find the "impure" order.
…On Thu, Feb 22, 2024 at 9:12 AM Marius0509 ***@***.***> wrote:
Considering the old version calculated impure orders, I think this should
also be a feature in the current version. It also wouldn't remove any
existent feature, the pure order can still be obtained using
--distinguishall.
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS7RYAEPKFEDFFBUQMDYU5363AVCNFSM6AAAAABDTBNOUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZHA4TOMBTGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
That sounds like a great idea. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think the widely accepted definition of the order of a scramble is how many times you need to execute it from the solved state in order for the cube to come back to the solved state. So, I don't think -o and --ordertree should output orders for the supercube unless --distinguishall is mentioned. If doing the lcm of every cycle doesn't work for puzzles with identical pieces, then an alternative approach is doing the lcm of every set's order.
For example, I think the scramble "R U' R U R U R U' R' U' R2" should have the order 3 on 4x4 (not 12), just like on the 3x3 cube.
The text was updated successfully, but these errors were encountered: