Defining Identical Piece in Solved State, values not contiguous

[DougCube]

I modified a working definition file's solved state to have some identical pieces but get this error:

11: ! values are not contiguous

Why must values be contintiguous here? Isn't it just to identify which pieces are unique and which are identical to each other?

My use-case is this. I want to branch a definition file with all unique pieces to a series of definition files with different subsets of pieces being identical. If I have say 8 corner pieces, I'd like to use the number "9" to denote the pieces I no longer want to "solve" because trying to pick say the lowest unused index may still leave gaps, and it would also force me to pick possibly different numbers for each new definition file when I'm trying to generate them in bulk.

CORNERS
1 2 3 4 5 6 7 8
0 0 0 0 0 0 0 0

to

CORNERS
1 2 9 4 9 9 9 9
0 0 0 0 0 0 0 0

Would it be possible to change the behavior and support such usage?

(I should probably start a separate thread for this:)
In addition, I would like a way to indicate certain pieces can ignore orientation within that "Solved" section -- not certain set of pieces but a subset of the same piece type. I realize that as a workaround I could switch to defining the set of 8*3 stickers (with no orientation) instead of 8 pieces (with 3 orientations), but that can become unwieldy.

[rokicki]

Howdy! Yeah, this is just a limitation at the moment. It's certainly possible that twsearch can renumber things internally (and then unrenumber things on output) but we just haven't written that code or added that data structure. There is some pressure to keep twsearch in C++ consistent with the ongoing work in Rust and the Typescript code, and that's going to be more challenging if we want to support noncontiguous definitions. It's not impossible, but I'm not sure we want to add the code in all three places, and I'm not sure the value of the feature outweighs the cost of the deviation. On the second request, it sounds strange to me to support both orientation and no orientation on the same piece type; if the pieces are interchangeable, how can one have an orientation and the other not? Doesn't the very fact that one actually has an orientation and the other doesn't make them distinct? And I don't see how decomposing the pieces with orientation into separate stickers resolves that issue. Can you give an example of how this would work?

…

On Sat, Nov 23, 2024 at 12:05 AM DougCube ***@***.***> wrote: I modified a working definition file's solved state to have some identical pieces but get this error: *11: ! values are not contiguous* Why must values be contintiguous here? Isn't it just to identify which pieces are unique and which are identical to each other? My use-case is this. I want to branch a definition file with all unique pieces to a series of definition files with different subsets of pieces being identical. If I have say 8 corner pieces, I'd like to use the number "9" to denote the pieces I no longer want to "solve" because trying to pick say the lowest unused index may still leave gaps, and it would also force me to pick possibly different numbers for each new definition file when I'm trying to generate them in bulk. CORNERS 1 2 3 4 5 6 7 8 0 0 0 0 0 0 0 0 to CORNERS 1 2 9 4 9 9 9 9 0 0 0 0 0 0 0 0 Would it be possible to change the behavior and support such usage? (I should probably start a separate thread for this:) In addition, I would like a way to indicate certain pieces can ignore orientation within that "Solved" section -- not certain *set of pieces* but a subset of the same piece type. I realize that as a workaround I could switch to defining the set of 8*3 stickers (with no orientation) instead of 8 pieces (with 3 orientations), but that can become unwieldy. — Reply to this email directly, view it on GitHub <#65>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLS72ELGNJPBQ7XLV57D2CAZODAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4DKNRSGMYTSOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[DougCube]

Let's say I want to take a 3x3x3 and solve only F2L. I want to ignore the orientation of LL corners and LL edges, but keep orientation on the F2L corner and edge pieces. Decomposing the pieces with orientation into separate stickers did workaround it for me because I can make all the stickers for pieces I don't care about identical to each other (within the same 'pieces' type).

[rokicki]

That should work just fine. Can you share a .tws file that doesn't work? You can use orientation wildcards on any piece, as long as all pieces that have the same label are either wildcarded or not wildcarded. In this case all LL pieces would be wildcarded and all F2L pieces would not be.

…

On Sat, Nov 23, 2024 at 12:49 PM DougCube ***@***.***> wrote: Let's say I want to take a 3x3x3 and solve only F2L. I want to ignore the orientation of LL corners and LL edges, but keep orientation on the F2L corner and edge pieces. Decomposing the pieces with orientation into separate stickers did workaround it for me because I can make all the stickers for pieces I don't care about identical to each other (within the same 'pieces' type). — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLSZKXAJGZPZANFBTEJD2CDS5HAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGY2TANZZGM> . You are receiving this because you commented.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[DougCube]

I don't know what you mean by "wildcarded." What is the syntax and how and where is it used?

[rokicki]

Use a question mark for the orientation in the "Solved" part: CORNER 1 2 1 2 2 1 1 2 0 ? 0 ? ? 0 0 ? End

…

On Sat, Nov 23, 2024 at 1:02 PM DougCube ***@***.***> wrote: I don't know what you mean by "wildcarded." What is the syntax and how and where is it used? — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLS4LILKO3G6NCT6VQSL2CDUN3AVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGY2TGOJUGU> . You are receiving this because you commented.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[DougCube]

Where is this feature documented?!

[DougCube]

Also, how would I apply this to a "ScrambleAlg" instead of a "Scramble?"

[lgarron]

For what it's worth, my experience with using masks makes me think this is pretty useful. In particular, I think it would be useful for a default masking algorithm to convert each identical piece to the lowest index of any of them, rather than the lowest index available. This is more stable when modifying or composing masks, and it can be a useful default while also allowing choices for hand-written patterns to use larger numbers for convenience.

[rokicki]

Wow, this may not be documented anywhere? Gee, that needs to be fixed. I don't think you can apply it to a ScrambleAlg as by definition a ScrambleAlg is only a set of moves. I don't see any logical connection to a ScrambleAlg.

…

On Sat, Nov 23, 2024 at 1:12 PM DougCube ***@***.***> wrote: Also, how would I apply this to a "ScrambleAlg" instead of a "Scramble?" — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLS7UWI5QHGGQ6VUCLED2CDVUFAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGY2TMMBUGA> . You are receiving this because you commented.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[DougCube]

I misread your last message. I through to place '?' in the scramble file not the definition file.

[rokicki]

It needs to go in both. The ?'s in the tws file need to match the ?'s in the definition file.

…

On Sat, Nov 23, 2024 at 8:45 PM DougCube ***@***.***> wrote: I misread your last message. I through to place '?' in the scramble file not the definition file. — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLS5CEOBHXN4SFODGGA32CFKXBAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVHAYDIOBTHA> . You are receiving this because you commented.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[rokicki]

The orientation wildcards are defined in docs/architecture.md about line 306.

…

On Sat, Nov 23, 2024 at 8:49 PM Tomas Rokicki ***@***.***> wrote: It needs to go in both. The ?'s in the tws file need to match the ?'s in the definition file. On Sat, Nov 23, 2024 at 8:45 PM DougCube ***@***.***> wrote: > I misread your last message. I through to place '?' in the scramble file > not the definition file. > > — > Reply to this email directly, view it on GitHub > <#65 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAMOLS5CEOBHXN4SFODGGA32CFKXBAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVHAYDIOBTHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

[rokicki]

I'm willing to implement support for noncontiguous permutation "labels" or "values". Need an upvote from @lgarron before proceeding, since this introduces a divergence from Rust/cubing.js and earlier discussions.

[lgarron]

Need an upvote from @lgarron before proceeding, since this introduces a divergence from Rust/cubing.js and earlier discussions.

Still in favor. As far as I can tell, this would strictly bring feature parity rather than divergence. I can't actually find any current code that enforces contiguous values in JS/Rust, and it should be easy to fix if we find any related assumptions in the future.