The aim was to match existing conventions as much as possible. Speffz is the strongest convention for face ordering I'm aware of, and ULFRBD matches it: https://www.speedsolving.com/wiki/index.php/Speffz
This has the convenience of matching "reading order" for the most common cube net layout used by cubers, most notably used by the WCA scramble program and most timers.
1.3 Why not call it a cubelet as I have heard very often?
I'd also like to avoid tying this terminology too much to "cub"es, since KPuzzle applies to many puzzles.
(Similar reason for using "facelets" instead of stickers".)
1.3.3. Why is only the order after the first letter arbitrary?
You can specify the orientation of an order using the location of just one facelet. For this, it's fairly straightforward to specify what's in the highest-priority facelet location.
I think it's a good idea for programs to be strict about order when possible, but humans use both clockwise and CCW informally — I think it would be annoying to reject URF when it's clear what a user meant.
1.3.7. Is the cube only solved if it is also standard orientated? Because colloquilly a cube is also considered solved if all cubelets are at their home place modulo any overall cube orientation. Maybe the better question is: How is a location defined?
The short answer is yes. I think it's best to think of a location as a region of space, relative to a fixed perspective.
If we consider centers fixed, it's not so much a problem. But you do have a good point — we need different definitions of "solved" for different puzzles. Perhaps it's best to define this as "canonical solved state" or "reference solved state", so that other definitions can be based on it. Any thoughts on that?
1.4.1. Why not index Faces exactly like the Axis? So the Face order is: R U F L D B ...
I think I answered this above; let me know if not.
For: https://github.com/cubing/standards/blob/gh-pages/draft/6/sign-lgn-notation/index.md
Base Move: It is not explained what a positive-int in a certain command means. e.g. I had at the beginning implemented that 2-2r means that from Layer 2 going on, two layers are involved. So I mistreated the 2nd integer as a length varibale rather than a inclusive endIndex
This is definitely a good point. I tried to focus specifically on syntax in this document, but I think it would be good to at least include an example of what the range notation commonly means.
In general what r/m/M/... means is not explained, you have to look at the alg visualizer ...
This is... still controversial. At this point, I think it's probably best to leave them out of the most basic "SiGN" notation, or make it less cube-centric.
What should be the reason to forbid 1r? I gues it is perfectly defined...
The motivation was that lowercase families in SiGN mean multiple slices. But I agree that this is well-defined, and some applications might need it, so it's probably worth allowing. Programs can use linters to recommend avoiding this for any relevant use cases.
Repeated Move: I think "base-move prime" is also allowed, right? I think "0" should be allowed for an angle, too. It happens at multiple locations that you can formulate a move that does nothing. Sometimes there is a difference between does nothing and moves nothing ...like R4 does nothing but you could visualize a move ...
Yeah, repeatable-unit prime definitely needs to be added. I also agree that it's most practical to allow 0
And yeah, R4 should definitely valid move, even if it does nothing on a cube. It's relevant for reconstructions (cubers regularly do U4 or U4' while solving), and if you don't know the puzzle you can't even tell if it does nothing — R4 does the same as R' in Megaminx.
SiGN Alg: Would it not make sense to allow an arbitrary number > 1 of whitespace between moves?
I wanted to keep SiGN as simple as possible to parse. If we allow an arbitrary number of spaces, then any program that says it accepts SiGN will need to support it. But if we say SiGN is single-spaced, this keeps things as simple as possible for programs that seek to meet a minimal spec.
LGN: In all structures I think it should be allowed to use an arbitrary amount of whitespace ...
Yeah, definitely agreed. I kept it simple in the original draft, but I think that makes a lot of sense. Unfortunately, though, there are different definitions of what counts as whitespace, but I'm hesitant to specify a list. :-P Any good ideas on a good existing list to match?
In general there should be a priority list that defines that I should rather e.g. write M instead of 2R in the 3-cube ...
What use cases do you have in mind for this?
For some use cases it's useful to canonicalize algs to some extent, but I can't immediately think of a good reason to have a universal list (although I'd love to hear one).
Why call it KPuzzle and not PuzzleSpecification or something else descriptive?
My personal reasons for this are:
To clarify that it's an opinionated way to describe certain permutation puzzles, not necessarily appropriate for all puzzles.
To acknowledge its origins from ksolve.
A short name that is not too generic.
But those reasons may not be so universal.
Is that really what an orbit is? I thought an orbit is a class of puzzleStates that you cannot leave via moves. e.g. a 3-cube with all solved is in another orbit as a all solved 3-cube where one edge is flipped.
This is going off the group-theory definition when we view piece permutations with moves as generators. (It's possible to specify puzzles where not all pieces in an orbit can end up in each other's place, but for most puzzles this will be possible.)
What you're describing sounds to me more like cosets in the physical assembly cube group, i.e. cosets of <U, L, F, R, B, D> in <U, L, F, R, B, D, twist UFR, flip UF, swap UF and UR>.
We could have here an openapi definition file that allows much more validation formalism than typescript interfaces
Would you be willing to prototype an example of this?
https://swagger.io/specification/ suggests that it's based on JSON schemes, which sounds like a good basis, but I don't know enough about OpenAPI to know if it would have additional benefits.
I think such a KPuzzle should also have a name, you can then have some kind of registry where you can talk about a kpuzzle without having to write it down explicitly
Agreed, we definitely names a bunch in cubing.js and I want to build a registry. However, there are some issues with assigning universal naming schemes and requiring all KPuzzle definition objects to have a name field:
It's possible to generate arbitrary puzzles, and we shouldn't force programs to generate names for those. (At best, we could compute a unique hash, but that's tricky for other reasons.)
I have not yet found a naming convention that works property across languages/the ecosystem. The WCA uses 333 for 3x3x3, but:
This can cause ambiguity when we support more puzzles in the future, e.g. between 333x333x333x333 (3D) and 3333x3333x3333 (3D). That's a bit contrived, but I think we're going to run into trouble with heuristics for simple cases (e.g. 33x33x33, which some programs might parse as 333 if written as 333333).
Most programming languages don't allow identifies that with numbers. This can get in the way of best practices and optimizations (it's already biting us in cubing.js, where we can't tree shake the exports of puzzle definitions).
I think a KPuzzle should define when it is considered solved like the difference between a rubic's cube and a supercube
We definitely need this. I really want the "de factor" 3x3x3 definition to include centers, but also to specify that 1) center orientation is ignored for state comparison by default, and 2) that any orientation counts as solved.
My best idea for #2 is to define orientation-agnostic comparisons against a normalized version of every state — e.g. "place these pieces at home before comparing". I'd love some ideas on where in the spec #1 could live without causing trouble.
Must all allowed moves be defined via this structure or is it possible to "compose" 2nd level moves from first ones like r=R+2R and how could I write this in a parameterized way... it would be cool if the move language was completly defined by a KPuzzle ...
I think it would be safe to specify that programs can assume r is the same net transformation as R 2R. Would love some thoughts on how to spec this safely.
The allowed moves are not just a set of moves. They have structure like the mapping to Faces. This should be able to say somehow...
Are you saying there should be a way for a def to communicate that an F is related to "the F face"? That sounds sort of appealing, but I haven't had any significant motivating use cases for this.
3x3x3 State Representations:
I can think of a state representation that aims more at the KPuzzle Spec, the there could be a facelet orientated one (just index them and give them all a color) and there could be a physical one where you have for every cubelet a inital location (location vector), current location (location vector) and a orientation matrix
This will definitely be useful. TwistySim has this: http://cube.rider.biz/twistysim.html#puzzledef
We also use PuzzleGeometry for this internally. By the time we get around to implementing Square-1, we'll definitely need something closer to what you describe. I personally think this should not be part of the KPuzzle spec, and should be another layer based on it, but perhaps we can discuss that in the future.
Responding to some good thoughts by @lukaslentner in Slack:
The aim was to match existing conventions as much as possible. Speffz is the strongest convention for face ordering I'm aware of, and ULFRBD matches it: https://www.speedsolving.com/wiki/index.php/Speffz
This has the convenience of matching "reading order" for the most common cube net layout used by cubers, most notably used by the WCA scramble program and most timers.
It seems "cubie" is definitely more common than "cubelet". @rokicki has some facts on this: https://cubing-org.slack.com/archives/CKCL6KBNY/p1613679081010900?thread_ts=1613573156.001400&cid=CKCL6KBNY
I'd also like to avoid tying this terminology too much to "cub"es, since KPuzzle applies to many puzzles. (Similar reason for using "facelets" instead of stickers".)
You can specify the orientation of an order using the location of just one facelet. For this, it's fairly straightforward to specify what's in the highest-priority facelet location.
I think it's a good idea for programs to be strict about order when possible, but humans use both clockwise and CCW informally — I think it would be annoying to reject URF when it's clear what a user meant.
The short answer is yes. I think it's best to think of a location as a region of space, relative to a fixed perspective. If we consider centers fixed, it's not so much a problem. But you do have a good point — we need different definitions of "solved" for different puzzles. Perhaps it's best to define this as "canonical solved state" or "reference solved state", so that other definitions can be based on it. Any thoughts on that?
I think I answered this above; let me know if not.
This is definitely a good point. I tried to focus specifically on syntax in this document, but I think it would be good to at least include an example of what the range notation commonly means.
This is... still controversial. At this point, I think it's probably best to leave them out of the most basic "SiGN" notation, or make it less cube-centric.
The motivation was that lowercase families in SiGN mean multiple slices. But I agree that this is well-defined, and some applications might need it, so it's probably worth allowing. Programs can use linters to recommend avoiding this for any relevant use cases.
Yeah,
repeatable-unit primedefinitely needs to be added. I also agree that it's most practical to allow0And yeah, R4 should definitely valid move, even if it does nothing on a cube. It's relevant for reconstructions (cubers regularly do U4 or U4' while solving), and if you don't know the puzzle you can't even tell if it does nothing — R4 does the same as R' in Megaminx.
I wanted to keep SiGN as simple as possible to parse. If we allow an arbitrary number of spaces, then any program that says it accepts SiGN will need to support it. But if we say SiGN is single-spaced, this keeps things as simple as possible for programs that seek to meet a minimal spec.
Yeah, definitely agreed. I kept it simple in the original draft, but I think that makes a lot of sense. Unfortunately, though, there are different definitions of what counts as whitespace, but I'm hesitant to specify a list. :-P Any good ideas on a good existing list to match?
What use cases do you have in mind for this?
For some use cases it's useful to canonicalize algs to some extent, but I can't immediately think of a good reason to have a universal list (although I'd love to hear one).
https://standards.cubing.net/draft/3/kpuzzle/
My personal reasons for this are:
ksolve.But those reasons may not be so universal.
This is going off the group-theory definition when we view piece permutations with moves as generators. (It's possible to specify puzzles where not all pieces in an orbit can end up in each other's place, but for most puzzles this will be possible.)
What you're describing sounds to me more like cosets in the physical assembly cube group, i.e. cosets of <U, L, F, R, B, D> in <U, L, F, R, B, D, twist UFR, flip UF, swap UF and UR>.
Would you be willing to prototype an example of this? https://swagger.io/specification/ suggests that it's based on JSON schemes, which sounds like a good basis, but I don't know enough about OpenAPI to know if it would have additional benefits.
Agreed, we definitely
names a bunch incubing.jsand I want to build a registry. However, there are some issues with assigning universal naming schemes and requiring all KPuzzle definition objects to have a name field:333for 3x3x3, but:333if written as333333).cubing.js, where we can't tree shake the exports of puzzle definitions).We definitely need this. I really want the "de factor" 3x3x3 definition to include centers, but also to specify that 1) center orientation is ignored for state comparison by default, and 2) that any orientation counts as solved.
My best idea for #2 is to define orientation-agnostic comparisons against a normalized version of every state — e.g. "place these pieces at home before comparing". I'd love some ideas on where in the spec #1 could live without causing trouble.
I think it would be safe to specify that programs can assume
ris the same net transformation asR 2R. Would love some thoughts on how to spec this safely.Are you saying there should be a way for a def to communicate that an F is related to "the F face"? That sounds sort of appealing, but I haven't had any significant motivating use cases for this.
This will definitely be useful. TwistySim has this: http://cube.rider.biz/twistysim.html#puzzledef We also use
PuzzleGeometryfor this internally. By the time we get around to implementing Square-1, we'll definitely need something closer to what you describe. I personally think this should not be part of the KPuzzle spec, and should be another layer based on it, but perhaps we can discuss that in the future.