• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

What Orientation do you use for Blindsolving?

Fair enough, but when the rest of the world likes to describe their orientation in terms of which faces (colours) move to U and to F, why do you think it's "clearer" for your notation to instead require them to specify where the UF edge moves to? And with a cryptic format too? It looks more like an attempt to make things less clear.

I like your proposal: it seems move active. I am in the process of updating my program, so I will support both formats. The old format @UF=RD specifies the result of moving into the BLD reading orientation of red up yellow front (for Western colored cubes). The alternative active motion format you like will now read @BL=UF, which also specifies red up yellow front. The "=" in computer science in some languages is ":=" and is pronounced 'becomes' -- it should be clear either way.

For programming purposes, I will ignore any request that does not have "UF" on either or both sides of the "equation". Of course, if "UF" is on both sides, the result is a no-op (no operation).
 
The old format @UF=RD specifies the result of moving into the BLD reading orientation of red up yellow front (for Western colored cubes). The alternative active motion format you like will now read @BL=UF, which also specifies red up yellow front.
You started out saying "@UF=XY" means UF moves to XY. If you move UF to RD you get blue top orange front. Same if you move BL to UF. Looks like you swapped the format so XY moves into UF, but that's OK as it makes more sense. I would probably just say "orientation = RD" though. Guess it depends who your users are.
 
CFOP got too boring for me so I switched to ZZ.
That being said, I don't really care about CN anymore so I try to solve only Grey top(Yellow for normal) Blue front.

Naturally, that became my BLD orientation as well.

So I use Grey(Yellow) Top/Blue front.
 
I like your proposal: it seems move active. I am in the process of updating my program, so I will support both formats. The old format @UF=RD specifies the result of moving into the BLD reading orientation of red up yellow front (for Western colored cubes). The alternative active motion format you like will now read @BL=UF, which also specifies red up yellow front. The "=" in computer science in some languages is ":=" and is pronounced 'becomes' -- it should be clear either way.

For programming purposes, I will ignore any request that does not have "UF" on either or both sides of the "equation". Of course, if "UF" is on both sides, the result is a no-op (no operation).
The @ in the notation refers to the niche or address that the following indicated edge cube sticker or section moves to -- by means of x, y or z moves (or [r], \[\u] or [f] to apply a little-used WCA notation for FMC. Applying that the destination address appears first will avoid misreading instead the inverse whole-cube rotation. It is also consistent with modern computer science (programmer's) notation.
 
Last edited:
You started out saying "@UF=XY" means UF moves to XY. If you move UF to RD you get blue top orange front. Same if you move BL to UF. Looks like you swapped the format so XY moves into UF, but that's OK as it makes more sense. I would probably just say "orientation = RD" though. Guess it depends who your users are.
Sorry I was vague about the notation. @UF=XY means that the cube is reoriented so that the UF location gets to refer to the cube sticker originally at XY. Similarly, @XY=UF is read so that the XY location gets the cube sticker formerly located at UF before the reorientation. This is consistent with most programming languages.
 
Last edited:
Back
Top