QuantumInfo: StdBasis refactor

[Timeroot]

This is a very large refactor, but it's also the kind of thing that made sense to do in one big sweep, and by nature it touches nearly everything in QuantumInfo.

The idea is to:

• Change density matrix (and bra, and ket) to stated in terms of hermitian operators, instead of matrices. Similarly for CPTPMap and others. (CPTPOp in general, for working on operators; CPTPMap for when it's on matrices.)
• Have a StdBasis instance that gives a "canonical" basis for much work, and a .toMatrix / .ofMatrix equivalence with the matrix form wherever that instance is available. This is heavily connected to EuclideanSpace as the space given on that basis then.
• Do definitions without StdBasis where possible (a basis-free proof), but one can also do them with a basis and then show they are basis-invariant. Both can be natural at times.

I think this will greatly increase the compatibility of the library with other efforts, down the line!

[github-actions]

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.

[goliath-klein]

Hi Alex.

My main impression: Going from concrete matrices to more abstract types is a great development!

(BTW: While I was traveling, @PrParadoxy has ported large parts of our QCLib from matrices to CLMs. See this branch)

Below are some high-level comments. I feel like I haven’t contributed enough to the project to criticize your work. So please read what follows as vague suggestions. So far I've only looked at StdBasis.lean and HermitianOp.lean, not at the, uh, 10k other lines in the diff. :-)

[goliath-klein]

I’m not convinced that the StdBasis approach is net positive. Compare it to this alternative:

1. Constructions (like the Pauli operators you mention) that rely on a distinguished basis are formalized as acting on EuclideanSpace (as in @PrParadoxy's branch linked to above)
2. Likewise, if a physical system comes with a canonic basis, it typically makes sense to formalize it, too, directly in terms of an EuclideanSpace.
3. There are exceptions. For example, a subspace of an already-formalized space, which come with a distinguished basis (let's say I have already defined a Hilbert space of functions, and now want to talk about a GKP code inside of it). But I’d say that’s not too common, and one can always use OrthonormalBasis.repr to pull back a EuclideanSpace-based construction.

As far as I can see, StdBasis would make things easier only in case 3.

But it comes with a price! All Mathlib defs that treat bases as explicit parameters have to be re-implemented using an instance-implicit signature. That leads to code duplication, and a steeper learning curve. Also, definitions (like e.g. a Clifford group implementation) using this Physlib-specific API will be harder to port / reuse in other contexts.

So my gut feeling is that this abstraction introduces more costs than benefits.

[goliath-klein]

One could also use existing constructions, like so:

noncomputable def toMatUnitary' (U : unitary (E →L[𝕜] E)) : Matrix.unitaryGroup ι 𝕜 := ⟨(Unitary.linearIsometryEquiv U).toMatrix stdBasis.toBasis stdBasis.toBasis, LinearIsometryEquiv.toMatrix_mem_unitaryGroup ..⟩

A related def from QCLib, which gives a star algebra equivalence:

noncomputable def unitaryGroupEquiv : unitaryGroup n 𝕜 ≃⋆* unitary ((EuclideanSpace 𝕜 n) →L[𝕜] (EuclideanSpace 𝕜 n)) := Unitary.mapEquiv (StarMulEquiv.ofClass (Matrix.toEuclideanCLM (𝕜 := 𝕜)))

[goliath-klein]

One could use the namespace _root_.Subtype.toMatUnitary to enable dot notation.

[goliath-klein]

I know this came up on Zulip, and you were a bit exasperated recalling the story of this type synonym. So sorry for brining it up again...

...but why is this a definition (semi-reducible, even)? Could one not just introduce a custom notation for the somewhat lengthy selfAdjoint (E →L[ℂ] E)? This would have the advantage of making much of the boilerplate that follows redundant (instances, like AddCommGroup; simp lemmas like op_zero, op_add, ...). It would also remove one discrepancy between the Physlib and the Mathlib way of saying things.

You mentioned performance issues on Zulip. Is that the only reason? If so, I'd be happy to offer help looking into their origin. Maybe a few shortcut instances can address it?

[goliath-klein]

One could make this definition much more general. E.g. like this:

noncomputable def selfAdjoint.cfc {R : Type*} [TopologicalSpace R] [Ring R] [StarRing R]
  [Algebra ℂ R] [ContinuousFunctionalCalculus ℂ R IsStarNormal] 
  (A : selfAdjoint R) (f : ℝ → ℝ) : selfAdjoint R :=
  ⟨_root_.cfc f A.val, cfc_predicate f A.val⟩

This def would cover both your intended use case selfAdjoint (E →L[ℂ] E), but also self-adjoint elements in a C^*-algebra.

[goliath-klein]

⟨_root_.cfc f A.op, cfc_predicate f A.op⟩: more information at essentially the same length.

(Side remark: I'm amazed the elaborator can figure out the predicate (IsSelfAdjoint) in the first argument of the constructor. It took me some time to understand what the definition does. So it's maybe not the best place to hide information).