Draft: Embedding with lazy semantics

[amilsted]

Basic version.

[codecov]

Codecov Report

❌ Patch coverage is 42.85714% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.35%. Comparing base (6d64805) to head (10464d1).
⚠️ Report is 115 commits behind head on master.

Files with missing lines	Patch %	Lines
src/operators_lazytensor.jl	42.85%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #88      +/-   ##
==========================================
- Coverage   96.46%   96.35%   -0.12%     
==========================================
  Files          26       26              
  Lines        3363     3370       +7     
==========================================
+ Hits         3244     3247       +3     
- Misses        119      123       +4     

☔ View full report in Codecov by Harness.
📢 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.

[Krastanov]

I am in favor of this getting merged. This new functionality is not exported, so changes to it will still be possible. QuantumSymbolics and QuantumSavory would like to use it already, so there will be feedback on it as well.

[amilsted]

Ok, perhaps I'll add some simple tests first.

[Krastanov]

Any chance we can remove the b::Basis argument? I would like to be able to make an object like "apply CNOT gate to subsystems 2 and 4" without having to commit to how many qubits I have.

[amilsted]

Any chance we can remove the b::Basis argument? I would like to be able to make an object like "apply CNOT gate to subsystems 2 and 4" without having to commit to how many qubits I have.

Huh, that's an interesting suggestion. Currently we define operators wrt to a concrete composite basis with integer indices. You could lazily embed operators on two qubits, then lazily embed the result into a larger system later. Not sure if that is currently supported, but it would be easy enough to do for the LazyTensor case.

Another useful feature for this kind of use-case would be a "labeled basis". If we had that, we could map from smaller <-> larger composite systems by label.

[Krastanov]

Maybe a first step would be to permit nothing or PlaceholderBasis() <: AbstractBasis in the basis field and just see how many things break. Then whenever a multiplication or similar operation is performed we create a new lazy object that steals the basis from whatever it is being multiplied with. It is not the most efficient way to do it, but we can do it in a relatively compiler-friendly way (and most importantly, without modifying much of the rest of the library).

Named bases would also be nice, but I consider them separate from this.

[Krastanov]

I converted this to draft, just to make it easier to track what I need to review on my github dashboard.