rokicki
commented
2 days ago 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 https://github.com/cubing/twsearch/issues/65, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMOLS72ELGNJPBQ7XLV57D2CAZODAVCNFSM6AAAAABSK2GRXKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4DKNRSGMYTSOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
--
DougCube
lgarron
I modified a working definition file's solved state to have some identical pieces but get this error:
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.
to
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.