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

Migrate express and AbstractRepresentation type from QuantumSymbolics #46

Merged
merged 9 commits into from
Jan 16, 2025

Conversation

apkille
Copy link
Collaborator

@apkille apkille commented Dec 22, 2024

Copy link

codecov bot commented Dec 22, 2024

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 16.95%. Comparing base (3d63b38) to head (7ce478a).
Report is 11 commits behind head on main.

Files with missing lines Patch % Lines
src/express.jl 0.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
- Coverage   17.29%   16.95%   -0.34%     
==========================================
  Files          12       13       +1     
  Lines         399      401       +2     
==========================================
- Hits           69       68       -1     
- Misses        330      333       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@apkille
Copy link
Collaborator Author

apkille commented Dec 22, 2024

Just a note: I moved

express(obj) = express(obj, QuantumOpticsRepr()) # The default representation

to here from QuantumSymbolics to avoid type piracy in QuantumSymbolics. This isn't urgent whatsoever, but I wonder how beneficial it is to have a default representation for express, given that the ecosystem of packages supported by QuantumInterface is growing. This might be a bad comparison, but it's kind of like if DifferentiationInterface were to make its default backend AutoForwardDiff because ForwardDiff.jl has been around a long time and is used by a lot of people. Those things are true and ForwardDiff.jl is quite a handy package, but there's a ton of other autodiff packages that someone might rather use instead. I think the same could be said here. It probably would be a clearer translation interface if the user always has to explicitly define what backend they want to plug into. Of course, this would be a breaking change, but I thought I should put that thought out there.

@apkille
Copy link
Collaborator Author

apkille commented Dec 30, 2024

@Krastanov

Copy link
Collaborator

@Krastanov Krastanov left a comment

Choose a reason for hiding this comment

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

Looks good. I posted more comments in QuantumSavory/QuantumSymbolics.jl#93

Only other thing here: could you add a

"""
Some short explanation
"""
function express end

after a bump of the version to 0.3.x+1 I can merge this and let you finish the one in QuantumSymbolics.

Do you have merge privileges for this repo?

@Krastanov Krastanov marked this pull request as draft January 16, 2025 16:57
@Krastanov
Copy link
Collaborator

Marking it as a draft to remove it from my review queue for now. Convert it back when ready and merge (or ping me to merge).

@apkille apkille marked this pull request as ready for review January 16, 2025 17:33
@apkille
Copy link
Collaborator Author

apkille commented Jan 16, 2025

@Krastanov should be good to go. I don't have merge privileges for QuantumInterface.

@Krastanov
Copy link
Collaborator

the kwdef error is because this was made public in 1.9. Prefacing it with Base.@kwdef should be enough

@Krastanov
Copy link
Collaborator

the jet errors are also on master. Could you bump the ignore count to 3. There are ways to make this more robust, but I have not had a chance to look into it yet

@apkille apkille merged commit 8f8c0e2 into qojulia:main Jan 16, 2025
10 checks passed
@apkille apkille deleted the express branch January 16, 2025 18:30
@Krastanov
Copy link
Collaborator

Just FYI, make sure that on similar PRs in the future you use "Squash and Merge" not "Merge", to keep the git history neat and easy to review. On most of the QuantumSavory repositories that is the default, but it is not the default here.

Of course, if you have neatly separated commits in your PR, just use "Merge". For folks that like to have neat commits in their PRs, they would usually add small fixes "junk" commits, have a reminder in the commit title (e.g. fixup: <actual title>) and then they would use rebase+squash to clean up before merging.

@apkille
Copy link
Collaborator Author

apkille commented Jan 16, 2025

Ah my bad, sorry about that. I'm so used to it being the default that I just pressed the green button. Thanks for the heads up.

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.

2 participants