Source code for those interested: https://github.com/corbett/QuantumComputing

That seems like a petty criticism. The code is very well formatted, variables are clearly named, it's indented well and consistently. I had no trouble reading and understanding the code, did you?

It's not necessarily my style to keep everything together, but that's what it is, a style. Code folding works great and is a feature of every editor I'm aware of.

I respectfully disagree, but I suspect this might be a disconnect between different Python communities. I find the code extremely difficult to parse. Even ignoring the egregious PEP-8 issues (and, I know that PEP-8'ing existing code can obfuscate commit history), there's too much logic on many lines. I strongly subscribe to the adage that "Code is read many more times than it's written".

The essence of your argument is "I don't understand because it's too hard for me"?

Maybe that's true --- it certainly is for me --- but since this is quantum computing, I wouldn't expect to just understand this code without at least some background in QM.

"Everything is hard before it is easy."

That's not quite what I was trying to say. What I was saying is that there's many splits in the Python community. I work on large distributed systems, and have zero experience with quantum computing or advanced maths.

But, I'm a curious individual. I'd love if the academic Python community (to try to put a label on it) would all write code that was "idomatic". I know that "idomatic" is a problmatic term, but specifically I'm asking for people to follow PEP-8 and generally follow the ethos of `import this`.

Once we're speaking a common vernacular, we can better share ideas.

Note that many researchers in fields other than computer science do not program for fun. They know their code isn't the best in the world, but they'd rather spend their time testing hypothesis rather than reading screeds about the "right way" of formatting some bits on their disk.

My experience with most other researchers' code is that taking the logic and rewriting the code is more efficient than trying to fix the code they've shown you. But they deserve respect for not evangelising formatting over function -- a form of respect I cannot extend to you.

Perhaps you should try building your own then?

And about a half of it is actually test code.

I realize this will probably be downvoted because it's not adding anything productive to the conversation but I agree with you 100%.

I'm running in to that with Go. Go even makes it super easy to break things out in to multiple files transparently and people still just toss everything in one file.

In this specific case, and I am a super pedantic, anal retentive when it comes to python, I really wish more people would use pylint / pyflakes / flake8. Use 4 spaces, order & organize your imports so I can easily see what's third party and what's core and as pointed out organize the code in to modules when it makes sense.

I know PEP-8 (& PEP-257) polarizes people and one of the biggest things I LOVE about Go is `gofmt` & `go vet`. Just follow a community standard so we don't spend so much brain power figuring out so many independent styles & conventions. And if everyone disagrees (pretty much everyone complains about 80 cols width) then it usually ends up coming up in other community discussions and the diversions become common and expected.

Rant over- tl;dr I really love community style / organization guidelines, code organization and linting.

Go even makes it super easy to break things out in to multiple files transparently and people still just toss everything in one file.

I've heard it phrased thus: "scrolling through one file is easier than jumping around between files", and that fits with my experience.

That said, although I'm not very familiar with Python, this file does have a lot of "verticality" with lines like

    t q[2]; 
    h q[2]; 
    h q[0]; 
    h q[1]; 
    ...

which I would try to express in a bit more compact form, and I'd think stuff like this could be better written with arrays and/or procedurally generated:

    self.three_qubits_000=np.kron(self.two_qubits_00,State.zero_state) 
    self.three_qubits_001=np.kron(self.two_qubits_00,State.one_state) 
    ...

Everyone doing it the same way is far more valuable than individuals doing everything 5% faster.

Every Python library I read is immediately accessible to me. This hasn't been the case for JavaScript.

I never understood why python allows both spaces and tabs as indentation. Even 2 or 3 spaces sometimes work.

It seems odd to allow this and then ask everyone to use 4 spaces.

Because tabs make much more sense (to me personally) and so I would like to use them, and not have a specific convention imposed on me.

You will always have syntax imposed on you. With python you have indentation imposed on you, whether you like it or not. In other languages, indentation is a style option.

Using tabs makes your python code (potentially) incompatible with other peoples code, due to a style convention. This seems utterly crazy to me.

Yes, I prefer tabs too, but this tabs/spaces/different number of space feels like if C had the option of using either curly braces or parenthesis for blocks.

Point taken. I wish the decision was done to standardise tabs rather than spaces. But since the convention is now spaces, at least in Python, it would do well do follow those conventions.

This has changed a little in Python 3 which disallows mixing the use of tabs and spaces for indentation.

> Even 2 or 3 spaces sometimes work.

What? Every number of spaces always works. Anyway, it's nice to separate style recommendations and syntax.

You mean the sub-directory level structure with a file somewhere that defines the name of your TODO app?

well, literally half of that are unit tests (starting at line 1370)

Oh, come on... this code is fine. Stop your naysaying.

Could someone please explain the difference (if there is one) between this simulator and Liquid (from Microsoft Research) [1]?

Liquid supports operating with ~30 qubits [2], so I'm wondering if Quintuple is able to do something else that Liquid doesn't offer.

[1] https://www.microsoft.com/en-us/research/project/language-in...

[2] http://stationq.github.io/Liquid/docs/LIQUiD.pdf (page 7)

The point of Quintuple is compatibility with the IBM Quantum Experience, so that you can noodle around on your own system before trying your program on the real thing. Is there an easily available quantum device on which I can run a Liquid program?

There are no available quantum devices and there won't be any for the next few years for sure.

Liquid is meant for simulations. Sure, you can run the same operations on the currently available research hardware (which is definitely not going to do anything useful, because the hardware "decoheres" way too fast).

And the notation that you use does not matter much - any program that you will try to run today would be so short and the hardware so experimental, that writing the control sequences by hand for the specific hardware would be the easiest part of the exercise.

Liquid can do everything this can do and more, except for the extremely simple parsing of that simple language.

My question might be very stupid, but I am genuinely curious:

I assumed a quantum computer is fundamentally different to a classical one and thus you needed actual quantum physics to build this kind of computer. So how can you simulate the quantum computer on a classical one?

We can mathematically describe how a quantum computer works, so we can implement the mathematics in a classical computer. It's just slow (=higher complexity) in comparison. A quantum computer AFAIK can't solve any problems a normal computer couldn't solve, but it is a lot more efficient for some of them.

> A quantum computer AFAIK can't solve any problems a normal computer couldn't solve, but it is a lot more efficient for some of them.

Technically correct, but some of the problems we want quantum computers to solve are currently infeasible by conventional means because of speed. Factorization for example, that's why public key encryption works (we can't brute force it), but a quantum computer could.

I didn't down vote you but here are a few remarks about your comment:

>> [..] but it is a lot more efficient for some of them.

> Technically correct

Not quite. We know algorithms which have better time complexity on a quantum than any known classical algorithm that solves the same problem. Shor's algorithm is an example. We are not sure if a classical algorithm with the same time complexity exists.

>Factorization for example, that's why public key encryption works (we can't brute force it), but a quantum computer could.

Most (all?) modern public key algorithms are not based on the integer factorization problem.

> >Factorization for example, that's why public key encryption works (we can't brute force it), but a quantum computer could.

> Most (all?) modern public key algorithms are not based on the integer factorization problem.

There are analogues for Shor's algorithm for the discrete logarithm and other similar problems.

Shor's algorithm covers discrete logarithm also.

But most modern asymmetric algorithms are based on elliptic curves and other problems that quantum computers don't help with.

The ECC algorithms used today rely on the "Elliptic Curve Discrete Logarithm Problem" and are very much vulnerable to (a version of) Shor's algorithm. Some would even say they are more vulnerable than RSA due to the much smaller key sizes (requiring less qubits).

You can simulate a quantum circuit with a classical circuit, albeit with exponential slowdown.

My understanding is that the "magic" of a quantum computer is that it quickly finds a solution in a search space that grows exponentially based on the size of the input. Therefore it can be simulated by enumerating the search space and iterating over it.

The simulation is based on describing the problem in terms of quantum computing and translating that description into a program executable by a Turing machine. The simulation allows testing the utility/correctness of programs for quantum computers.

So glad to see more hobby-level projects happening in the software/simulation side of quantum computing.

I could criticize some of the design choices, but honestly they're all fine for 5 qubits. Quirk also started out with hacks that worked fine for a handful of qubits, then fell on its face and required rewrites and profiling as I tried to get it past 10.

Could you help us understand what the limiting factor in these simulations are?

By memory considerations alone, a N-qubit wavefunction (using 64-bit floats) uses 2^(N+4) bytes, and a N-qubit unitary operator uses 2^(2N+4) bytes. If you use 1 GB of RAM, that allows you to store full unitary operators up to 13 qubits.

If you use sparse operators to store the gates (which have a size in memory that is a constant times the wavefunction size) you can imagine doing 24 qubits.

Of course fighting exponential scaling is always hard, but I'm not sure if I understand why the limit (for a hobby-level project) is closer to 10 than 24.

Quirk was hitting a limit before 10 due to time costs, not space costs. Avoiding the matrices also saves you a lot of time because you can apply M 2-qubit gates to N qubits in O(M 2^N) time. Usually M is much smaller than 2^N (e.g. for the Fourier transform M is O(N^2)), so this is huge savings over the naive matrix multiplication.

(Also keep in mind that Quirk's nature applies a lot of time pressure. It animates and reacts as you drag circuit elements around, so I only have ~100ms to simulate a whole circuit from start to finish and draw the results before the experience starts to really suck. Having minutes or hours instead of centiseconds is a big help when it comes to having more qubits.)

Another side note: there are ways to simulate millions of qubits using a GiB of RAM. BQP is in PSPACE. The problem is it requires doing the equivalent of path integrals, and there will be lots and lots and lots of paths. All of the space costs get turned into time costs that are exponential in the number of operations... so not actually viable for more than a handful of extra qubits.

Cool, thanks for the info. I enjoyed playing with Quirk, it's very nice.

Christine is living the life, currently in Antarctica: https://twitter.com/corbett

Did anyone get the example code at https://github.com/corbett/QuantumComputing to work? I always get "'QuantumRegisterCollection' has no attribute 'get_qubit_named'". Scanning through the source code, I also couldn't find a function that might do the same thing under a different name.

EDIT: Literally found it a minute after typing this: It's called 'quantum_register_containing'.

It's a little odd to me that this project is presented so explicitly as being linked to the IBM Quantum Experience because the IBM Quantum Experience has a built-in simulator already. Having something open-source is nice because then you can modify it and try other things, but then it wouldn't be modeling the IBM system any more.

As someone who's a bit out of the loop, what are some good resources for learning about quantum computing?

Scott Aaronson's blog and his lectures notes at MIT. His book "Quantum Computing since Democritus" is quite great as well, no matter whether you are a researcher or just a layman.

If you want to delve deeper in the Quantum Physics side of things try "Quantum Computation and Quantum Information" by Nielsen and Chuang (PhD level textbook).

There are tutorials in the IBM Quantum Experience that go through the basics of manipulating qubits and putting opertions together into small quantum circuits.

+1

Why a fixed five qubits? Why not four or six?

Genuinely curious.

I assume because the IBM service this emulates also has 5.

That's what IBM did in their recent announcement.