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

Unify implementations of custom measurements and custom resets #1985

Merged
merged 2 commits into from
Oct 30, 2024

Conversation

orpuente-MS
Copy link
Contributor

@orpuente-MS orpuente-MS commented Oct 30, 2024

This PR unifies the implementations of custom measurements and custom resets. It does two things:

  • Removes the CallableKind::Measurement variant from HIR and FIR.
  • Uses the Attr::Measurement to identify that a callable is a measurement.

Copy link
Member

@minestarks minestarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the motivation behind the change, so I can't judge it based on that, but the code changes look good to me.

@orpuente-MS
Copy link
Contributor Author

orpuente-MS commented Oct 30, 2024

I don't know the motivation behind the change, so I can't judge it based on that, but the code changes look good to me.

Just to leave some context documented here. When implementing custom measurements a couple of PRs ago, I encoded the fact that an operation was a measurement as the new (now removed) CallableKind::Measurement variant. It looked like a good idea at the moment because measurements are treated different in theory and literature.

In the next PR when adding reset operations, an edge case came afloat, the MResetZ operation, which is a measurement and a reset at the same time. So, taking @swernli suggestion, instead of adding more variants to the CallableKind enum, I just piped down the attributes of a callable (@Measurement, @Reset, etc.) and used that information to determine if an operation was a reset, which happened to be simpler and more scalable when adding new attributes in the future.

In this PR I just undid the addition of the CallableKind::Measurement variant and used the infrastructure already added for resets, the piped-down attributes, to determine if an operation is a measurement.

@orpuente-MS orpuente-MS added this pull request to the merge queue Oct 30, 2024
Merged via the queue into main with commit bedd810 Oct 30, 2024
18 checks passed
@orpuente-MS orpuente-MS deleted the oscarpuente/measurements-resets-unification branch October 30, 2024 22:38
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

Successfully merging this pull request may close these issues.

3 participants