Skip to content
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

Commutator slash notation #300

Open
adiwastu opened this issue Nov 7, 2023 · 6 comments
Open

Commutator slash notation #300

adiwastu opened this issue Nov 7, 2023 · 6 comments

Comments

@adiwastu
Copy link

adiwastu commented Nov 7, 2023

Would it be possible to further expand the comms notation beyond the standard [S: [A,B]]? Nowadays, with comms that cancels with its own conjugation, BLDers often find the use of slash notation [S: [A/B]] to shorten comms and ease the learning process to basically "skip" the cancellation thought process. Expanded, [A/B] would be A B A2 B' A. For example, [U: [R' D' R, U2]] would simply rewritten as [U'/R' D' R]. I've been using ACN as a tool to learn comms by simply copying and pasting said comms and see it animates (I believe others did too), and with the rising usage of slash notation, more and more sheets had implemented it just because how simple it is. it would be amazing if ACN could also support this! Thanks!

@lgarron lgarron transferred this issue from cubing/alg.cubing.net Nov 7, 2023
@rokicki
Copy link
Contributor

rokicki commented Nov 7, 2023 via email

@adiwastu
Copy link
Author

adiwastu commented Nov 8, 2023

unfortunately, no. the closest explanation for this would be Elliot's video when they released their 3BLD sheet (I clipped it to the relevant timestamp)

basically, it could be used whenever a pure comm (8 mover) is conjugated with a setup move (1 move) but the setup cancels with the insertion, making the total comm being a 9 mover, or as BH classified them as A9.

edit: I believe I made mistake by saying A9 is relevant to this slash, as upon further inspection, it do share the same similar thing (as in it cancels to a 9 mover comm) but comms descibed as A9 isn't the exact same thing as comms with slash notation I mentioned before. hope this is fine!

@lgarron
Copy link
Member

lgarron commented Nov 8, 2023

The main question in my mind is: will this notation be around in 20-50 years?

There is a high bar for new notation syntax like this, since it would require adding a new container to the syntax along Grouping, Commutator, Conjugate and requiring every compatible implementation to support it. There are a variety of conjugate and commutator notations we don't support, in favor of a small set of stable syntax.

In addition:

  1. Using the slash as a separator is not an option, since that would conflict with parsing of the Square-1 / move. We'd have to use a different separator, similar to how we needed to tweak NISS notation.
  2. This seems to be underdocumented/underexplored to the point of contradiction?
  • Shouldn't [U'/R' D' R] expand to [U': [R' D' R, U2]] rather than [U: [R' D' R, U2]]?
  • A B A2 B' A looks like an incorrect expansion to me. I'm guessing it should actually be A B A2' B' A?

If the notation is more widely documented and used I think it might be reasonable to consider, but in my view it has a significant way to go before meeting that bar.

@adiwastu
Copy link
Author

adiwastu commented Nov 9, 2023

The main question in my mind is: will this notation be around in 20-50 years?

Judging from how recently it is being introduced and how quickly it is being adopted as the preferred notation to communicate such comms which that cancelling property, in which said comms are abundant in practice, in my opinion, I'd say this notation would easily still be around for quite a while.

There is a high bar for new notation syntax like this, since it would require adding a new container to the syntax along Grouping, Commutator, Conjugate and requiring every compatible implementation to support it. There are a variety of conjugate and commutator notations we don't support, in favor of a small set of stable syntax.

In addition:

  1. Using the slash as a separator is not an option, since that would conflict with parsing of the Square-1 / move. We'd have to use a different separator, similar to how we needed to tweak NISS notation.

Right, I totally got squan notation under the radar. Perhaps this could be overcome by context? Like when the active puzzle is a cube, then the slash would be interpreted as a cancelled comm, and when the active puzzle is a squan, then it adjusts accordingly. I'm not sure how the code works and whether it could be significantly more complex if that was implemented.

  1. This seems to be underdocumented/underexplored to the point of contradiction?

This being underdocumented is of course true, as I was only able to provide 2 resources about that on my first comment. However, I'd like to see this being underexplored as untrue, as the BLD community is constantly using this to communicate comms with, as much as normal comms notation. The following addition you pointed is unfortunately a mistake in my part in writing the stuff though.

  • Shouldn't [U'/R' D' R] expand to [U': [R' D' R, U2]] rather than [U: [R' D' R, U2]]?

Yes, you're correct. [U: [R' D' R, U2]] is, instead, the expanded version of [U/R' D' R].

  • A B A2 B' A looks like an incorrect expansion to me. I'm guessing it should actually be A B A2' B' A?

I am not sure if A2 and A2' is any different? Because in slash notation, A will always be the interchange, and it won't work if the order is swapped (like a normal comm would work). This adds the point of this not being feasible to implement widely, though, as I think it more. the inverse of [U/R' D' R] is [U'/R' D' R] (inversing the A) and swapping the A and B would never work.

Really appreciate your points and views on this so far though!!

@lgarron
Copy link
Member

lgarron commented Jan 16, 2024

Apologies for the slow response — I think my latest reply draft got lost.

Judging from how recently it is being introduced and how quickly it is being adopted as the preferred notation to communicate such comms which that cancelling property, in which said comms are abundant in practice, in my opinion, I'd say this notation would easily still be around for quite a while.

I don't quite follow this reasoning. Quick adoption could just as well indicate a fad, in the absence of other evidence.

Right, I totally got squan notation under the radar. Perhaps this could be overcome by context? Like when the active puzzle is a cube, then the slash would be interpreted as a cancelled comm, and when the active puzzle is a squan, then it adjusts accordingly. I'm not sure how the code works and whether it could be significantly more complex if that was implemented.

This would contradict the design goals of cubing/alg in setting a baseline for parsing compatibility in the ecosystem. It is not an option.

I am not sure if A2 and A2' is any different? Because in slash notation, A will always be the interchange, and it won't work if the order is swapped (like a normal comm would work). This adds the point of this not being feasible to implement widely, though, as I think it more. the inverse of [U/R' D' R] is [U'/R' D' R] (inversing the A) and swapping the A and B would never work.

I think you might be making some unwarranted assumptions, which muddles my understanding of how the notation is meant to work. For one, R2 and R2' are not the same move in general — they differ on Pyraminx or on Megaminx, for example.

I don't want to imply that this kind of feature is impossible, but remain unconvinced that there are clear syntax and semantics that warrant enshrining it as permanent notation at this point. Ideally, I'd like to see more uses in the wild (or examples that need workarounds that would benefit from this use case), as well as more cubers eager to use this notation actively.

@lgarron
Copy link
Member

lgarron commented Jan 16, 2024

I'll leave this issue open for now, in case we see more advocacy for this across the community in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants