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

Improve operator support for new assert_equal function: Group 1 #5644

Open
albi3ro opened this issue May 3, 2024 · 8 comments · May be fixed by #5780
Open

Improve operator support for new assert_equal function: Group 1 #5644

albi3ro opened this issue May 3, 2024 · 8 comments · May be fixed by #5780
Labels
unitaryhack Dedicated issue for Unitary Fund open-source hackathon

Comments

@albi3ro
Copy link
Contributor

albi3ro commented May 3, 2024

Context

PennyLane currently has a qml.equal function which can be used to check the equality of operators, measurements, and tapes. While this has been extremely useful in testing and validation, it can be difficult to figure out why two objects aren't equal.

This is why we are currently have added the framework for an assert_equal function:

def assert_equal(

>>> from pennylane.ops.functions.equal import assert_equal
>>> assert_equal(qml.S(0), qml.T(0))
AssertionError: op1 and op2 are of different types.  Got <class 'pennylane.ops.qubit.non_parametric_ops.S'> and <class 'pennylane.ops.qubit.non_parametric_ops.T'>.

The framework for this function was added in PR #5634 , but the implementation still needs to be updated.

Implementation Details

Comparison currently relies on a _equal single dispatch function, with different "kernels" registered for different types of operators. Currently this function returns True or False. We are changing it to return True, or a string that explains why the two operators are not equal. This change has already been made for BasisRotation:

def _equal_basis_rotation(

This task is to update _equal for

While more single dispatch kernels exist for _equal, they will be updated as part of separate tasks.

After this PR, we should be able to do something like:

>>> assert_equal(qml.adjoint(qml.RX(0.1, wires=0)), qml.adjoint(qml.RX(0.2, wires=0)))
AssertionError: op1 and op2 have different base operations because op1.data[0] is not equal to op2.data[0]. Got 0.1 and 0.2.
>>> assert_equal(qml.exp(qml.X(0), 0.5j), qml.exp(qml.X(0), 1.0j))
AssertionError: op1 and op2 have different coefficients. Got 0.5j and 1.0j.

Use your best judgement as to the contents of the string and we will help refine the message if needed.

Additional Requirements

To fulfill this task, a PR should:

  • Update _equal kernels for the above cases
  • Update tests in test_equal.py. Existing tests like, test_adjoint_comparison can be extended, or new tests can be written.
  • Add a changelog entry
  • Pass black, pylint, and isort checks
@albi3ro albi3ro changed the title Improve support for new assert_equal function Improve operator support for new assert_equal function May 3, 2024
@trbromley trbromley changed the title Improve operator support for new assert_equal function Improve operator support for new assert_equal function: Group 1 May 6, 2024
@trbromley trbromley added the unitaryhack Dedicated issue for Unitary Fund open-source hackathon label May 29, 2024
EuGig added a commit to EuGig/pennylane that referenced this issue May 31, 2024
…tion: group 1

As suggested in [PennyLaneAI#5644], makes kernels _equals_operators, _equal_controlled
_equal_pow, _equal_adjoint and _equal_exp return either True or a string
explaining why two operators are not the same.
EuGig added a commit to EuGig/pennylane that referenced this issue May 31, 2024
…tion: group 1

As suggested in [PennyLaneAI#5644], makes kernels _equals_operators, _equal_controlled
_equal_pow, _equal_adjoint and _equal_exp return either True or a string
explaining why two operators are not the same.
EuGig added a commit to EuGig/pennylane that referenced this issue May 31, 2024
…tion: group 1

As suggested in [PennyLaneAI#5644], makes kernels _equals_operators, _equal_controlled
_equal_pow, _equal_adjoint and _equal_exp return either True or a string
explaining why two operators are not the same.
EuGig added a commit to EuGig/pennylane that referenced this issue May 31, 2024
…tion: group 1

As suggested in [PennyLaneAI#5644], makes kernels _equals_operators, _equal_controlled
_equal_pow, _equal_adjoint and _equal_exp return either True or a string
explaining why two operators are not the same.
@Tarun-Kumar07 Tarun-Kumar07 linked a pull request May 31, 2024 that will close this issue
@Tarun-Kumar07
Copy link
Contributor

Hi @albi3ro and @trbromley,

I’ve submitted PR #5780. Once the PR is merged, could you please assign this issue to me before closing it?

Thank you!

EuGig added a commit to EuGig/pennylane that referenced this issue Jun 3, 2024
…tion: group 1

As suggested in [PennyLaneAI#5644], makes kernels _equals_operators, _equal_controlled
_equal_pow, _equal_adjoint and _equal_exp return either True or a string
explaining why two operators are not the same.
@trbromley
Copy link
Contributor

Thanks a lot @Tarun-Kumar07! Really excited to see some unitaryHACK contributions coming in 🧑‍💻

It looks like @EuGig has also opened a PR for this issue:

We like to encourage working together as much as possible if it works for both of you. Would it make sense for @Tarun-Kumar07 to take on #5648 and @EuGig to take on #5644?

@EuGig
Copy link
Contributor

EuGig commented Jun 3, 2024

Sounds good to me!!

@trbromley
Copy link
Contributor

Awesome, what do you think @Tarun-Kumar07?

@Tarun-Kumar07
Copy link
Contributor

Hi @trbromley and @EuGig,

I am open to collaboration. While working on #5644, I had to make some changes due to failing unit tests, which also addressed #5648. I attempted to separate the changes, but it seems they need to be in one PR. I have completed the changes for both issues and only waiting for the feedback.

If you feel there are still some gaps, @EuGig, I would be happy to collaborate further to address them.
Thanks !!

@Tarun-Kumar07
Copy link
Contributor

@EuGig and @albi3ro, I noticed that the comments @albi3ro made about the tests in PR #5778 are similar to the changes I've implemented in my PR #5780. To avoid duplicating efforts, @EuGig and I could collaborate on PR #5780.

What do you guys think?
@albi3ro, @trbromley and @EuGig

@trbromley
Copy link
Contributor

@EuGig and @albi3ro, I noticed that the comments @albi3ro made about the tests in PR #5778 are similar to the changes I've implemented in my PR #5780. To avoid duplicating efforts, @EuGig and I could collaborate on PR #5780.

What do you guys think? @albi3ro, @trbromley and @EuGig

Thanks @Tarun-Kumar07, that can work! So the proposal is:

If that's good for both of you, then I think it's a great idea.

@Tarun-Kumar07
Copy link
Contributor

@trbromley Sounds good to me!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unitaryhack Dedicated issue for Unitary Fund open-source hackathon
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants