Live data from Hacker News

A tutorial quantum interpreter in 150 lines of Lisp

stylewarning.com

31–40 of 46 posts

Re: A tutorial quantum interpreter in 150 lines of Lisp

#31
post #29

Earlier quoted context omitted.

One of the aspects emphasized in TFA is being able to simulate gates of any dimension/number of qubits (like a 3-qubit Toffoli or a 5-qubit Molmer-Sorensen), instead of just 1- and 2-qubit gates. Have you thought about extending your simulator to support gates of greater than two qubits?

I know about the conventional 2-qubit Molmer-Sorensen but not the 5-qubit version. Could I ask what it is?

See e.g. equations (5) and (6) from [1], where any qubit subset of a system might undergo the action of the M–S gate. But definitely the usual presentation of the physics of M–S is on a two qubit system.

[1] https://arxiv.org/abs/1601.06819

Re: A tutorial quantum interpreter in 150 lines of Lisp

#32

Recently, I have been working on some things that sometimes overlap with quantum computation and I have realized that the way all the quantum languages approach this wrong. If you are programming explicitly with CNOT gates, you are doing it wrong. A Python programmer doesn't care about logical gates, and neither should a quantum programmer. To that end, I'm convinced that the interplay between coinduction and inducti…

(disclaimer: I work on the team developing Q# and its tooling)

That's part of the goal of Q#. It's designed to be a language which allows you to build up from quantum gates, efficiently work with quantum concepts such as 'adjoint' and 'controlled' operations, and build that up into a higher level of abstraction. You can see an old post as to some of the reasoning when it was first developed at https://devblogs.microsoft.com/qsharp/why-do-we-need-q/>.

Another consideration to some of the points raised here, is that even on today's state-of-the-art hardware you typically only get a couple thousand gates at best before noise overwhelms the system and the qubits 'decohere' (https://en.wikipedia.org/wiki/Quantum_decoherence). So you do often want to develop at a level where you can squeeze every last gate out of whatever program you're writing. (If you intend to run it on a quantum computer and not just simulations).

Being that the post is about quantum simulation, you can see the one our team built in Rust at https://github.com/qir-alliance/qir-runner/blob/main/sparses... . This uses 'sparse' simulation, which means any state with a probability of 0 isn't tracked, which turns out to be quite a few in a lot of algorithms. This allows you to simulate many more qubits than you can with a full state simulator (where you need to track 2^n states for n qubits). It also does some other nifty tricks where you can elide or combine gates before they are performed to get even more perf. We use it in our new Q# stack (https://github.com/microsoft/qsharp) to run program simulations in our CLI or in the browser (such as on our new https://quantum.microsoft.com site), or inside VS Code (desktop or web)).

We are looking to evolve the Q# language and improve the quantum development experience, with a focus given to a 'scalable' quantum future where gate count and noise is less of a limit, and moving development higher up in abstraction - as you outline. So if it is something you have an interest in, we're more than happy to get the input on the qsharp GitHub repo linked to above.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#33
post #32

Recently, I have been working on some things that sometimes overlap with quantum computation and I have realized that the way all the quantum languages approach this wrong. If you are programming explicitly with CNOT gates, you are doing it wrong. A Python programmer doesn't care about logical gates, and neither should a quantum programmer. To that end, I'm convinced that the interplay between coinduction and inducti…

(disclaimer: I work on the team developing Q# and its tooling) That's part of the goal of Q#. It's designed to be a language which allows you to build up from quantum gates, efficiently work with quantum concepts such as 'adjoint' and 'controlled' operations, and build that up into a higher level of abstraction. You can see an old post as to some of the reasoning when it was first developed at https://devblogs.micros…

TBH I was never quite sold qubits. Is analog quantum out of the question?

Re: A tutorial quantum interpreter in 150 lines of Lisp

#34

Recently, I have been working on some things that sometimes overlap with quantum computation and I have realized that the way all the quantum languages approach this wrong. If you are programming explicitly with CNOT gates, you are doing it wrong. A Python programmer doesn't care about logical gates, and neither should a quantum programmer. To that end, I'm convinced that the interplay between coinduction and inducti…

> the interplay between ... coalgebra and algebra If you have not already seen it, you may be interested in Squiggol (to get an idea of its age, it probably had some indirect influence upon Python) cf Charity: https://prism.ucalgary.ca/server/api/core/bitstreams/756b50a...

I have seen Charity yes, total functional programming is the future.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#35
post #19

Earlier quoted context omitted.

I never said that they weren't. It's just that most programming language don't deal with gates as a part of their API.

This is true, but at that point, the goal would be to have a higher level language above the quantum gates. And at that point, I'd guess the code is less educational? That is, at the end of the day, something like Shor's algorithm can be reduced to some math constructs we roughly know. The speedup comes from these only being efficient using quantum gates. Implementing the code using abstract quantum gates isn't to tr…

> That is, at the end of the day, something like Shor's algorithm can be reduced to some math constructs we roughly know.

Ok, what's the programmatic model there then?

Re: A tutorial quantum interpreter in 150 lines of Lisp

#36
post #25
post #3

The hardest part of implementing a quantum state vector simulation is understanding how the tensor product expands an n-qubit gate to apply to an m-qubit system. (A third of the linked post is dedicated to it; appropriately.) If you use a language or framework that's based on tensors to start with, things can be quite succinct (though you still need to understand the concepts). For example, in numpy, if you store the…

> The hardest part of implementing a quantum state vector simulation is understanding how the tensor product expands an n-qubit gate to apply to an m-qubit system. (A third of the linked post is dedicated to it; appropriately.) This feels like it could be the "git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space" of physics.

It's not, tensor products are of fundamental importance in QM. Understanding them is a hard requirement.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#37
> In Common Lisp, the matrix is written #2A((1 2) (3 4)).

I do understand that the row view and column view are symmetrical in linear algebra. But nevertheless, unless I'm really getting something wrong, matrices are typically (at least in undergraduate mathematics courses) introduced as collections of _column vectors_: the matrix is a linear transformation that sends a vector into the space spanned by those column vectors. And you can see this by how common it is to define vectors to be column vectors, e.g. using x^T notation to indicate that, or saying it explicitly. So, if I'm not wrong there, why do all programming languages define matrices as collections of rows??

Re: A tutorial quantum interpreter in 150 lines of Lisp

#38
post #10

I'm deciding between Common Lisp and Mojo, so maybe I will try to implement this in Mojo and compare. Anybody have any thoughts on this, since I am a mediocre Lisper and a beginning Mojo person. I am familiar with Numpy and I also program in APL and J.

Dude Common Lisp 100%!

Don't fret if you think you're mediocre. I myself have been trying to get through On Lisp since 2008. Then, after that, Let over Lambda. Not better, but v strong book, i can tell the guy while not the best at humblebragging has so much cool stuff there.

ANSI Common Lisp n that's plenty to not be mediocre! I did get through the whole thing in 2009, what a great book!

Re: A tutorial quantum interpreter in 150 lines of Lisp

#39
post #10

I'm deciding between Common Lisp and Mojo, so maybe I will try to implement this in Mojo and compare. Anybody have any thoughts on this, since I am a mediocre Lisper and a beginning Mojo person. I am familiar with Numpy and I also program in APL and J.

Dude Common Lisp 100%! Don't fret if you think you're mediocre. I myself have been trying to get through On Lisp since 2008. Then, after that, Let over Lambda . Not better, but v strong book, i can tell the guy while not the best at humblebragging has so much cool stuff there. ANSI Common Lisp n that's plenty to not be mediocre! I did get through the whole thing in 2009, what a great book!

the back-cover blurb of Let over Lambda is worth reading.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#40
post #10

I'm deciding between Common Lisp and Mojo, so maybe I will try to implement this in Mojo and compare. Anybody have any thoughts on this, since I am a mediocre Lisper and a beginning Mojo person. I am familiar with Numpy and I also program in APL and J.

Dude Common Lisp 100%! Don't fret if you think you're mediocre. I myself have been trying to get through On Lisp since 2008. Then, after that, Let over Lambda . Not better, but v strong book, i can tell the guy while not the best at humblebragging has so much cool stuff there. ANSI Common Lisp n that's plenty to not be mediocre! I did get through the whole thing in 2009, what a great book!

Thanks for the motivation. I love Lisp, and even was into Shen[0] for a while, but Common Lisp has all the libraries and legacy tutorials and books that I will stick it out a bit more. Which matrix/math libraries do you recommend to compete with the likes of Numpy and Mojo for ML apps? Because I love APL, April, Array Programming Re-Imagined in Lisp[1].

[0] https://shenlanguage.org/

[1] https://github.com/phantomics/april

Post reply on HN