What is a ket? How do traits work? Quantum computing in Rust, part 1
walther.guruThis does not present the correct definition of a ket. More specifically, it doesn’t present a reasonably general definition of a ket. It would be like asking “What is a list?” and implementing a data structure that can store only one element.
In quantum computation, a ket is a vector in a Hilbert space. A Hilbert space is just a fancy way to describe a typical space you find in linear algebra, where the space allows you to compute lengths and angles. When discussing kets, the usual vector space is the set of complex-element vectors with unit length (or “norm”). The vectors can have any number of elements (or “dimension”), but when discussing qubits, they are 2^n-dimensional for n qubits.
(It’s important to note that a ket is not distinguishable from a vector. It’s actually called so because of a notational convention, not because it has deeper underlying meaning. However, physicists will still use the word “ket” instead of “vector” or “quantum state” even if they’re not emphasizing notation.)
More interesting, though, is how kets combine with other kets via tensor products. This ingredient is as essential to QC as flour is to cake.
This article [0] informally presents a fully general definition of a ket along with the tensor product with an emphasis on why a representation and notation was chosen. But it does require a good understanding of linear algebra already.
[0] “Someone shouts |01000>! Who’s excited?” https://arxiv.org/abs/1711.02086
Thank you for feedback! Going to read the paper to improve my understanding. I'm writing this blog series in part to learn more - both about quantum computing as well as Rust. As some people say, teaching is a great way to learn (or at least check your knowledge).
What do you think would be a good correction or disclaimer to add? Would it be sufficient to e.g. say that in this first part, we only implement a two-component ket? Generalizing the ket type to an arbitrary-size vector while keeping type constraints, perhaps briefly mentioning const generics (an upcoming language feature), etc could easily make for another part in this series. Making the ket into an actual vector could then give way to doing proper linear algebra on them, cleaning up some of the manually implemented operations here, as their teaching purpose has been fulfilled already.
Thoughts?
I would say you’ve implemented a state vector for a single qubit (when the norm = 1 and when equality is defined to be phase invariant, i.e., x and y are equal whenever there’s an ‘a’ such that e^(ia)x = y.), which can be written down notationally with a ket:
|s> = p|0> + q|1>
where p and q are complex, and |p|^2 + |q|^2 = 1. The ket is the notation |s>, |1>, and |0>, which could also be written purely as column vectors.
At the end it all depends on what you want to present. What will be the climax? Unitary evolution of a pure state? Superoperators on a mixed state? An introduction to linear algebra used in quantum computation and its notation?
In any case I’d present what a quantum state is on N qubits, which requires 2^N-element complex vectors that satisfy a few properties.
Having "quantum computing" in the title makes this genuine clickbait when the body lacks any explanation of what a state is or what a ket is. Energy or momentum or spin states are rarely (never, in reality) just numbers.
You made no attempt to explain what the two different states in a single ket mean: hint, it's superposition. Never provided even a trivial justification for why normalization is important; where is the actual physics?
Using Rust here is also quite pointless when you're just doing linear algebra... where is the actual benefit over Python or even Haskell?
You've written a very cute and inefficient math library, but calling this QC is just false advertising.
Thank you for your feedback!
You're right, the essay needs a better explanation on what a ket and a quantum state is. I'll figure something out.
Excellent point with the superposition, I'll add that in! Same with the normalization - while adding the `is_valid` method to the struct makes sense programming story -wise, it'd be great to justify its origins and implications.
As for using Rust being pointless - I am writing this blog post series for three reasons: learning more Rust by doing, learning more quantum computing by doing, and sharing my journey as a tutorial. Using Rust for the sake of learning (and hopefully helping others learn) Rust is in my opinion a perfect reason to use Rust.
As for calling this QC - I'd clarify that this code does not intend to be a production-grade QC library, and the blog post series does not intend to be an exact, axioms-and-proofs type of an university level course that prepares you for the industry in one go. I'd think of it more as a Todo MVC app building journey with a quantum flavor - or something. That being said, I do plan to add more QC features in the next posts of the series, and incrementally add to the accuracy as much as I feasibly can. All this feedback here and links to more materials are helping me immensely, I want to learn more about this stuff!
Thank you for calling it very cute - I really appreciate that! ️
McIntyre or Griffiths' QM might be useful.
> (It’s important to note that a ket is not distinguishable from a vector. It’s actually called so because of a notational convention, not because it has deeper underlying meaning. However, physicists will still use the word “ket” instead of “vector” or “quantum state” even if they’re not emphasizing notation.)
This is not correct when you start talking about continuous-variable states. In the (canonical) position basis, the state of an infinite-dimensional system is commonly expressed as \ket{\psi} = \int \psi(x)\ket{x}dx. Here {\ket{x}} are a basis set, but not square-integrable, since \bra{x}\ket{x} = deltafunction(0). Hence \ket{x} is not a valid quantum mechanical state.
Kets sometimes even represent vector-valued functions (e.g., |f(t)> = e^(iHt)|0> or so) which in and of themselves aren’t states, but representations of system dynamics. We could pontificate as to whether |f(t)> is the function or is merely the image of t -> |f(t)> at some t. :)
In any event, I’m speaking in the context of my comment and of the article: (gate-based) quantum computation. Here, 9 out of 10 dentists will use a ket to denote the (computational) state of the quantum computer. Infinite dimensional states and bases aren’t pertinent at the level of logical computation.
> In quantum computation, a ket is a vector in a Hilbert space
The blog implements kets as 2-dimensional complex vectors, so I don't see any problem there. A 2-dimensional space is a Hilbert space.
It’s woefully under-representing what a ket can be, and the data structure isn’t amenable to extension to a broader set of states. A one qubit state lives in a Hilbert space just as a one element list is still a list.
`assert_eq(A == B, true)`? `assert_eq(A, B)`, or even `assert(A == B)` by all means.
And this does not really explain what a `Ket` is, rather unfortunately. I now know it's a pair of complex numbers, but that's not very handy - and the `is_valid` definition is not explained, so I don't even get told what subset of pairs of complex numbers make up valid kets without reading code.
Heh, what a silly little mistake to make with the asserts. I've now improved their readability. Thank you!
You're right, I need to add a better explanation for what a ket is. Same applies to the validity, should explain a bit about normalization.
Thanks for the feedback!
The title of the article is "Quantum Computing fin Rust, part 1", so the implication is that it is there to teach you about Rust, not to teach Quantum Mechanics which you already know.
It's not too much to expect an article entitled "What is a ket?" to explain what a Ket is.
Your point is arguable if it was instead "How to implement a Ket in Rust", and even then it's a bit vague. I left with the same feeling that it was a bit barebones in terms of definition.
Thank you all for the feedback! I'll continue to make improvements to this post, as well as build more in the next parts.
My current understanding is mostly based on this wonderful website: https://quantum.country/qcvc - if you can recommend more good resources, I'm all ears!
Forgot to mention, I'm also getting the book "Quantum Computing Since Democritus" by Scott Aaronson soon.
Really interesting. Rust is on my radar. You might be interested in a post in Haskell that I made that has a similar feel.
Oh thats pretty cool, wanted to subscribe to rss/atom feed for a followup blog posts, but cant find any feed link. I hope i wont miss future posts in series.
https://en.wikipedia.org/wiki/Bra%E2%80%93ket_notation
I remember learning about this at uni in one of the more advanced QM modules.
I remember thinking: Seriously, couldn't they've come up with a better name?
It's basically a 90-year-old pun involving splitting the word "bracket" into "bra" and "ket".
Why bracket? The reason is that there is not only ket vectors |v> but also functionals <u| that can be applied to them, which will look like this <u|v>. So there are brackets around the construct. Think <bra|ket> if you like.
Sometimes I don't know whether to be proud of or disappointed in our species.
Yeah, it's not like any programmers have ever come up with bizzare and useless names for abstractions.
Clearly OT but the excessive reliance on foo and bar in many of my early C lang learning examples really slowed down my ability to transfer said techniques into something meaningful. Eventually one of my friends working in the Visual C++ team (I'm dating myself here) explained the connection of foo and bar to fubar and kind of felt like this!
I had the same experience; that's mostly what I'm referencing. Trying to use things like The Hacker's Dictionary (largely in-jokes, bad jargon, and obnoxious circular definitions) to clear it up made the problem worse. I get that it's just a humor book, but still.
The word "quark" is kind of whimsical, but the names of the types of quark seem arbitrary and unhelpful.
it is strange that you have such a charming notion about the flavours of quarks. If we turn this notion upside down maybe we could then get to the bottom of this or should i say the top?
I'll see myself out