start of QuantumToolboxExt

[jeffwack]

This is incomplete, but I have made some progress on #116 and have some questions. My strategy was to copy the file QuantumOpticsExt and go line by line to convert to QuantumToolbox. I ran into name collisions (basis and \otimes) come to mind, so I decided to be conservative and use the QuantumToolbox.function() form for all function calls.

I ran into a roadblock converting this:

const xyzopdict = Dict(:X=>_x, :Y=>_y, :Z=>_z)
const xyzstatedict = Dict(:X=>(_s₊,_s₋),:Y=>(_i₊,_i₋),:Z=>(_l0,_l1))
for control in (:X, :Y, :Z)
    for target in (:X, :Y, :Z)
        k1, k2 = xyzstatedict[control]
        o = xyzopdict[target]
        gate = QuantumToolbox.tensor(proj(k1),_id) + QuantumToolbox.tensor(proj(k2),o)
        structname = Symbol(control,"C",target,"Gate")
        let gate=copy(gate)
            @eval express_nolookup(::$(structname), ::QuantumToolboxRepr) = $gate
        end
    end
end

Specifically, you cannot copy() a QuantumToolbox operator. This example shows the error:

using QuantumToolbox
copy(sigmap())

So, to avoid type piracy we cannot implement the conversion as written without contributing a method for copy() to QuantumToolbox?

Another route would be to rework that chunk to avoid the copy, but I am not so clear on how it does what it does. Why the macro?

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.18%. Comparing base (d11c261) to head (2122383).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
ext/QuantumToolboxExt/QuantumToolboxExt.jl	91.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #121      +/-   ##
==========================================
- Coverage   76.48%   76.18%   -0.30%     
==========================================
  Files          20       21       +1     
  Lines         842      886      +44     
==========================================
+ Hits          644      675      +31     
- Misses        198      211      +13     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[apkille]

Specifically, you cannot copy() a QuantumToolbox operator. This example shows the error:

Could you just print the error here? It makes review and answering questions faster.

Another route would be to rework that chunk to avoid the copy, but I am not so clear on how it does what it does. Why the macro?

Notice that the for loops are iterating through Symbols. Here's a discussion on what @eval does that probably is helpful.

So, to avoid type piracy we cannot implement the conversion as written without contributing a method for copy() to QuantumToolbox?

Yeah, if you do want a new copy method for the QObjs, I would recommend submitting a PR to QuantumToolbox rather than committing type piracy here. Although that's really not necessary, there's a bunch of different ways you could define the express_nolookup methods here. To help understand what the chunk does, note how we do it in actually defining symbolic objects like (XCXGate and ZCYGate) in the source code:

QuantumSymbolics.jl/src/QSymbolicsBase/predefined.jl

Lines 119 to 132 in a4980ef

	const xyzsuplabeldict = Dict(:X=>"ˣ",:Y=>"ʸ",:Z=>"ᶻ")
	for control in (:X, :Y, :Z)
	for target in (:X, :Y, :Z)
	structname = Symbol(control,"C",target,"Gate")
	label = xyzsuplabeldict[control]*"C"*xyzsuplabeldict[target]
	declare = :(@withmetadata struct $structname <: AbstractTwoQubitGate end)
	defsymlabel = :(symbollabel(::$structname) = $label)
	instancename = Symbol(control,"C",target)
	definstance = :(const $instancename = $structname())
	eval(declare)
	eval(defsymlabel)
	eval(definstance)
	end
	end

When defining the conversion in QuantumOptics, we are looping through each permutation of the two qubit gates and lining them up with the spin operators defined in QuantumOptics.

[ytdHuang]

@jeffwack @apkille

Hi, I'm one of the developers in QuantumToolbox.jl.

For your information, we have just merged a pull request (qutip/QuantumToolbox.jl#486) to implement copy method for our quantum objects.

This will be available in our next release v0.32.0, which is scheduled maybe next week.

[ytdHuang]

@jeffwack @apkille

Just an update to you, we have released QuantumToolbox v0.32 (see our ChangeLog)

[apkille]

@jeffwack what's the status on this PR? I can help you finish it if you want.

[jeffwack]

@apkille That sounds great to me! Apologies, I let this fall off my todo list. If you want to take this over that is fine by me :)

[apkille]

@Krastanov should be good to go for review!

[Krastanov]

looks good to merge once we figure out what the test failures are

we also might want to start having separate test runners for each extension, but this is beyond the scope of this PR

[Krastanov]

just marking it as an actual review:

• downgrade test
• changelog
• some other failing tests that might just be flaky (but checking that any JET tests failurs are unrelated)

Feel free to merge without checking with me once these are resolved, or tag me if they are weird to deal with / unrelated.

[apkille]

@Krastanov the downgrade test is weird to me/I'm not sure how to deal with it, it looks like a project.toml issue with QuantumToolbox and SciMLOperators:

caused by: Unsatisfiable requirements detected for package SciMLOperators [c0aeaf25]:
 SciMLOperators [c0aeaf25] log:
 ├─possible versions are: 0.1.0-1.3.1 or uninstalled
 ├─restricted to versions 1.3.1 by an explicit requirement, leaving only versions: 1.3.1
 └─restricted by compatibility requirements with QuantumToolbox [6c2fb7c5] to versions: 0.3.0-0.4.0 — no versions left
   └─QuantumToolbox [6c2fb7c5] log:
     ├─possible versions are: 0.5.4-0.32.1 or uninstalled
     ├─restricted to versions 0.32.0 by QuantumSymbolics [efa7fd63], leaving only versions: 0.32.0 or uninstalled
     │ └─QuantumSymbolics [efa7fd63] log:
     │   ├─possible versions are: 0.4.12 or uninstalled
     │   └─QuantumSymbolics [efa7fd63] is fixed to version 0.4.12-dev
     └─restricted to versions * by project [db1e3c79], leaving only versions: 0.32.0
       └─project [db1e3c79] log:
         ├─possible versions are: 0.0.0 or uninstalled
         └─project [db1e3c79] is fixed to version 0.0.0

the other two CI tests look to be unrelated caching issues for QuantumOpticsRepr and CliffordRepr translations.

[Krastanov]

this seems related qutip/QuantumToolbox.jl#470

[apkille]

@Krastanov Shall we merge this and create issues for the failing tests and deal with them in future PRs? I can do that this week during JuliaCon.

[Krastanov]

I think this will be causing actual issues to some folks. I would not be surprised if this issue pops up in a lot of environments that use QuantumSavory.jl. I would prefer to wait at least for a comment from the QuantumToolbox folks, because this might be unfixable without their commitment, and I would prefer not to have a future PR removing this extension.

[apkille]

Ok, sounds good

[ytdHuang]

@Krastanov @apkille

Hi guys,

Sorry for the long wait.

We have just released QuantumToolbox v0.34.0 to support SciMLOperators v1.4.

We don't support the versions between SciMLOperators v1 - v1.3 since there exist large extra memory allocations and also some incorrect results (at least for our runtests).

[Krastanov]

Wonderful! I closed/reopened the PR to rerun the tests.

[ytdHuang]

Ahh, the JuliaRegistry Bot is still running lol.

Maybe need a few minutes to get QuantumToolbox v0.34 merged in the registry

[ytdHuang]

Should be ready

[apkille]

@Krastanov the remaining two failing tests are unrelated to this PR. Shall we merge?

[apkille]

@Krastanov ping

[apkille]

OK, will merge in the next day if there's no disagreements between now and then

[Krastanov]

apologies for the slow responses and thanks for the prompt (generally, do not hesitate to aggressively use "will merge in the next few days if there is no dissent")

[Krastanov]

The compat for quantuminterface might need to be bumped to make Downgrade happy.

[Krastanov]

The macos test is just a flaky test

[Krastanov]

If the Downgrade test works now, feel free to merge. But generally let's avoid merges where non-flaky tests are failing.

[apkille]

Hmm looks like a compat issue with Gabs, I'll deal with this.

Edit: also some of the failing tests from bff6ce0 are due to this circular dependency SciML/RecursiveArrayTools.jl#477, which has been fixed.

[Krastanov]

The very last bump is a bit annoying. Pushing SymbolicUtils to 3.13 which is actually the cause of this bug of ours #100 -- well, not exactly bug, rather a feature downgrade. But now at least we are consistent on all platforms and do not need to worry about @test vs @test_broken

[Krastanov]

Thanks, everyone! Sorry about the delay on this, it seems we have had a messed up downgrades CI for a while

[apkille]

Thanks for seeing the downgrade tests through @Krastanov!