A tutorial quantum interpreter in 150 lines of Lisp • Hacker News Board

Re: A tutorial quantum interpreter in 150 lines of Lisp

#41

Post by eggy » Mon, Jul 17, 2023, 8:55 AM UTC

Archit3ch wrote: post #28

eggy wrote: 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.

May I suggest Julia? Efficient and capable of (Common Lisp style) abstractions. Unsurprisingly, there are more than a few quantum projects in the ecosystem already.

I've used Julia with Pluto and Weave to create engineering calculations and reports when I was working at an engineering company, but I want something more general purpose. I've used CL for little scripts and utilities with Portacle, and I find I am more comfortable with the Lisp way of doing things. I had used Mathlab before, so Julia's syntax is very familiar. I do like the Models.jl library.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#42

Post by gcr » Mon, Jul 17, 2023, 10:37 AM UTC

jxf wrote: post #25

Strilanc wrote: 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.

Quantum Country does a good job of explaining the fundamentals like “what is a Hadamard gate”! Highly recommended: https://quantum.country/

Re: A tutorial quantum interpreter in 150 lines of Lisp

#43

Post by taeric » Mon, Jul 17, 2023, 2:09 PM UTC

adamnemecek wrote: post #35

taeric wrote: post #19

Earlier quoted context omitted.

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?

At a higher level, it is "prime_factors(n)", no? The Shor's part could be said as a smaller part, but it is still doing something we have named.

Again, though, these programs are not to write an algorithm in quantum code. These are to understand the building blocks of a quantum computer. Just as a BDD/ZDD can be used to find optimal gate designs of an added built on boolean chains. You first have to understand the boolean chains.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#44

Post by reikonomusha » Mon, Jul 17, 2023, 11:11 PM UTC

da39a3ee wrote: post #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 v…

Programming languages usually have arrays, not matrices, and I think row-ordered array data has been a natural way to think in many fields (e.g., databases, finance, etc.), especially when you consider that adding a row ought to be less burdensome than adding a column in these contexts.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#45

Post by adamnemecek » Tue, Jul 18, 2023, 12:35 AM UTC

taeric wrote: post #43

adamnemecek wrote: post #35

Earlier quoted context omitted.

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

At a higher level, it is "prime_factors(n)", no? The Shor's part could be said as a smaller part, but it is still doing something we have named. Again, though, these programs are not to write an algorithm in quantum code. These are to understand the building blocks of a quantum computer. Just as a BDD/ZDD can be used to find optimal gate designs of an added built on boolean chains. You first have to understand the bo…

To be honest, quantum computers might come and go, I want to see what is the invariant that will stay the same across all of them.

Re: A tutorial quantum interpreter in 150 lines of Lisp

#46

Post by da39a3ee » Wed, Jul 19, 2023, 5:26 AM UTC

reikonomusha wrote: post #44

da39a3ee wrote: post #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 v…

Programming languages usually have arrays, not matrices, and I think row-ordered array data has been a natural way to think in many fields (e.g., databases, finance, etc.), especially when you consider that adding a row ought to be less burdensome than adding a column in these contexts.

I see, thanks I guess you're right. I'd been thinking of languages with matrices that support matrix operations but yes I think perhaps I'd been missing the point you make that it would be confusing for those to be list-of-column if list-of-row is used elsewhere in the language. It's a bit of a shame for working with matrices.