TBTK v2.0 – Second Quantization for C++ | Hacker News Reader

TBTK v2.0 – Second Quantization for C++

second-quantization.com

14 pointsdafer455 comments

Open articleView on HN

I wasn't sure what second quantization was so I lookep it up.

Full classical: physical quantities are scalars (x, p), fields are classical fields (E, B)

Semiclassical (first quantization): physical quantities are now operators.

Full quantum (second quantization): all fields are now field operators.

from wikipedia, second quantization is a misnomer:

> The term "second quantization" is a misnomer that has persisted for historical reasons. At the origin of quantum field theory, it was incorrectly thought that the Dirac equation described a nrelativistic wave function (hence the mistaken "Dirac sea" interpretation), rather than a classical spinor field which, when quantized (like the scalar field), yielded a fermionic quantum field (vs. a bosonic quantum field).

> One is not quantizing "again", as the term "second" might suggest; the field that is being quantized is not a Schrödinger wave function that was produced as the result of quantizing a particle, but is a classical field (such as the electromagnetic field or Dirac spinor field) that was not previously quantized. One is merely shifting from a semiclassical treatment of the system to a fully quantum-mechanical one.

That’s correct. However, the formalism is widely known as second quantization within the physics community. It’s therefore the terminology that is used in practice.

There already were a few of these in C++, most notably the tensor contraction engine. Mine was written in mathematica.

https://github.com/jparkhill/Symbolic-Many-Fermion-Codes

I would love to see one in rust there'd be real advantages for asynchronous parallelism in some of the most sophisticated models.

> I would love to see one in rust there'd be real advantages for asynchronous parallelism in some of the most sophisticated models.

Could you expand on this? it's my understanding that these engines already use lapack/blas for higher dimension numerical calculations, which are already parallelized.

Sure-- there's really two operations going on here. Finding the contractions needed for a properly indistinguishable quantum expectation value (there's a geometric number with the number of quantum particles ie: A_ij \cdot B_ji + A_ij \cdot B_ij \rightarrow C_ij for two particles), and then evaluating those tensor contractions in-silico. Exactly as in ML frameworks like PyTorch/TF, these contractions are executed as: unravel tensors ==> matrix multiply ==> Reravel. Sometimes there might be more than one contraction too, and more than two tensors. The order of raveling, factorization etc. completely controls the efficiency assuming you're always getting near peak in your matrix multiply with several orders of magnitude separating best/worst. Batching out the different factorizations, contractions etc. even just for the symbolic logic is a huge combinatoric problem.

Reply on news.ycombinator.com