Draft: Embedding with lazy semantics

[amilsted]

Basic version.

[codecov]

Codecov Report

Merging #88 (10464d1) into master (6d64805) will decrease coverage by 0.12%.
The diff coverage is 42.85%.

@@            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     

Impacted Files	Coverage Δ
src/operators_lazytensor.jl	95.84% <42.85%> (-0.88%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[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.