-
Notifications
You must be signed in to change notification settings - Fork 66
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
What metric do we use for Square One? #364
Comments
I suppose everyone agrees that at least "(x, y)" and "/" are different moves? |
Penalty-wise "(6,6)" is two moves. |
The only notation I have heard of is the "twist metric" with God's number = 13, which is also mentioned on Jaap's website. But as @viroulep said, in accordance with the regulations it would make more sense to count "(x,y)" as two moves. |
Somewhat related, can the regs/guidelines clarify the metric? I see a lot of people saying their unofficial scramble is only, for example, 9 twists, and thinking it's not a legal scramble. |
Not sure how much changes would be required to fix this...
Also according to our penalties right now:
We usually define the limit for penalties as "half a move", so if we consider (x,y) as two moves, we need to change the penalty's limit for square one to 15°. It would remain the problem of detecting misalignment during inspection, but it would be fixed by making paper blockers mandatory (not using them leaves a huge room for issues anyway, regardless of the metric used). |
I support changing the limit to 15 degrees and making the thin objects mandatory. One concern I have is that judging misalignments will be difficult, especially for judges who are not familiar with Sq-1. That is another good reason to restore example images (#17). |
Uhm, sorry, but I consider the idea of reducing that limit to 15° (and likely even keeping / as 90°) pure insanity in practice. I just quickly browsed through Youtube to see how many currently valid solves would have been a +2 under this rule and found two popular examples right away: Helmer's 6.67: https://www.youtube.com/watch?v=oBWpvyjmpXU Moreover:
Wouldn't this whole issue be also fixed if the regulations (or guidelines) simply define the metric based on what we currently use? E.g:
|
|
According to my understanding, this clearly means 45° for U and D layers on a SQ1. :) |
What do you mean by "currently use"? The metric you define here is not the metric defined by TNoodle (used for scramble filtering). See my original post for a description of what TNoodle currently does. If we define (1, 0) as "not a move", this is going to cause problems for TNoodle's filtering, because the search algorithm will prefer to do (1, 0) (1, 0) instead of (2, 0). Even if we do change TNoodle to avoid doing "redundant" moves like that, it's almost certainly going to alter the state space of possible scrambles TNoodle generates. I think there's an inherent dichotomy here between:
From both a software and a philosophical point of view, I do not like the definition of |
I never said anything about the middle of a solve. But doing (1,0) on a solved SQ1 is resembles exactly the same as doing a 30° rotation of the U layer on a solved 3x3x3. Basically, you can define moves for SQ1 in whatever way you want, but changing penalties for SQ1 only to match this definition, even though this makes no sense in practice, is quite ridiculous. If 10f+) doesn't fit this, then add an exception: 10f+) EXPLANATION The misalignment limits are selected so that they provide a natural cutoff between one state of a puzzle (without penalty) and a state one move away. Exception: Since a Square-1 has cubic shape in solved state, its U and D layers are judges analogously to a cubic puzzle. |
I want to revise my reply from above: I did not really think about what 15 degree actually means on a SQ-1. Sorry about that and I agree with @SAuroux's view regarding judging: I doubt that even the best judges in the world would be able to judge these misalignments in a consistent and fair way. Additionally, we would see either an enormous amount of +2s or results would get worse. After watching several videos of recent SQ-11 records I would guess about 50% of the solves have a misalignment of at least 15 degrees on one layer. |
How about implement Sébastien's proposal for calculating penalties and keep the current filtering of scrambles? E.g. define two type of moves, one of which is needed to determine penalty, and another one will be used only by WST? Another idea is to move the whole 4b3 into a separate document, and then only one type of moves will need to be defined for square-1. Competitors themselves don't need to know such nuances, so newcomers won't be overwhelmed with the information they don't need. |
Yes, I agree that defining two types of moves is the most reasonable way to implement an applicable limit for misalignments while not changing TNoodle's filtering. |
Yeah then two definitions (moves and penalties) sounds like the right path. We should also use this opportunity to fix some weirdness we still have with Square one. @SAuroux, I clearly remember, but couldn't find, an incident about a square one in a weird state but which was definitely +2 under the current Regulations. I remember you being involved in the discussion, would you happen to remember the competition in which it occurred? I'll try to take this issue on before the end of the week. |
I managed to find it with a quick Gmail search: Ukrainian Nationals 2017 report I'm still convinced that this should continue to be a +2 state. :) |
IIRC I judged a Square-1 solve that was off by (-1, 1) and 89° of a /-move. So that wasn't even a +2 but a normal time, though it looked halfway scrambled to (newb) me. |
(Moving the discussion over from thewca/tnoodle#153.)
See regulation 4b3d, which calls for at least 11 moves on Square One and 12c, which defines notation, but doesn't tell you what is considered a move.
I suppose right now, TNoodle is the de-facto standard for this. You can see the cost computation code here: https://github.com/cubing/tnoodle/blob/c6c0f6650e10d4ae76467532deb19a2504de9b67/scrambles/src/puzzle/SquareOnePuzzle.java#L216-L233, which says that something like
(5, 2)
is cost 1. However, Chen Shuang's Square One solver actually considers(5, 2)
to be 2 separate moves. See https://github.com/cubing/tnoodle/blob/c6c0f6650e10d4ae76467532deb19a2504de9b67/sq12phase/src/cs/sq12phase/FullCube.java#L78-L84.We could speed TNoodle Square One generation up quite a bit if we resolve this discrepancy. See TNoodle comment here.
The text was updated successfully, but these errors were encountered: