▲ 97 points
back
26 comments
Interesting! (For me it looks like "Nielsen Chuang in your browser".)
As I am curious since I am developing some quantum simulation on my own (https://github.com/stared/quantum-game - one photon, but spatial degrees of freedom and more physical interactions).
Side remark - for plotting states:
- did you consider using colors (see http://nbviewer.jupyter.org/github/qutip/qutip-notebooks/blo...)?
- is there some slider, so I can lookup state at any stage (not only the last one)?
> did you consider using colors
I did consider it, but I never experimented with it. For a small number of qubits, I think oriented circles are much clearer. Then they get gradually worse as you move up towards 16 qubits. Once the amplitudes get close to pixel-sized, you're probably forced to use color if you want to show a decent 1-to-1 representation.
Some of the downsides:
- Color-blind unfriendly.
- Worse absolute accuracy at a glance. I can guess the absolute angle of a short line to within a couple degrees (~100 distinguishable buckets). For hues that's probably more like 20-30 buckets, though relative comparisons would still be ~100 buckets accurate. The angular velocity at a glance probably also suffers.
- Circular motion, where the center is not at 0 (e.g. watch the X^t gate), won't look quite so circular.
- I already use color to hint at meaning (green is densities/probabilities, blue is amplitudes, yellow is volatility).
> is there some slider, so I can lookup state at any stage (not only the last one)?
Drag an amplitude display (the green 'Amps' thing in the toolbox) onto the circuit. Put it where you want to see the state. Resize it to cover everything.
(At the moment the inline displays are limited to covering 8 qubits. I was worried about performance when they get large. It'll be fixed in the future.)
Edit: Gah, there's a bug where the amplitude display is showing 'NaN' unless all the covered qubits are not entirely Off. Not sure how that slipped in.
Edit #2: Oh, it's happening on my work machine but not on my home machine. So probably related to webgl being terrible.
I'd like to second the color blindness concern. As someone with a color vision deficiency (deuteranopia, commonly known as red-green color blindness), I can't even enumerate the times I've been unable to complete some task because of a color coding which I couldn't distinguish. Worse yet, it often takes me a long time of trying to figure out how I'm supposed to know something before I suddenly stop and go "Oh, this might be color coded."
In high school, whenever I felt that I suddenly couldn't follow some explanation on the whiteboard, that's when I knew the drawings were color coded. The fact that things were color coded was usually communicated implicitly. Often, this is done by drawing two sets of things in different colors, usually red and green, and then just pointing at one instance from each category while giving some explanation regarding that category. This is simple, possibly not even a conscious choice, and it works perfectly as long as the students have the slightest bit of logical reasoning skills... and can actually tell that there are multiple colors being used.
Fair points with colors. While I still see some of their advantages (e.g. see there: http://imgur.com/esAxcEL) - thank you for brining me their downsides. (Also, very likely I will use "clocks" as an alternative vis for my own projects!) However, one thing that I think could be better for clocks is that when probability is small, then it phase is less important (I know the circle; but maybe opacity changing with log-probability?).
For measurement in between - the things that are there are interesting. But I was thinking about some mouseover - when you get full plot (intensity, phases), as something built-in. For not time-dependent circuits it would be cool to lookup step-by step.
In any case, this time-dependent operators is a thing beyond-expectations, so special thanks for that!
I am a newb dev, so I am curious to know what you used to build the simulator. You name-dropped webgl, but what else is needed to put together something like this, with the nice drop down menus, the drag and drop, and all that?
The drag-and-drop is done from scratch. Quirk just listens to browser events like mousedown/mousemove/mouseup and turns that into manipulations of the circuit. Getting it to work well across all the browsers, and modes of interactions, is quite finicky. For example, mobile browsers refused to not scroll even if `event.preventDefault()` was called, so I had to overlay the drag targets with transparent divs that have `touch-action: none`.
Quirk doesn't have menus.. you might be thinking of the recording of Davy's simulator? Those menus also look custom-made. I actually wouldn't call them "nice", because they lack important polish. Read this: http://bjk5.com/post/44698559168/breaking-down-amazons-mega-...
I'm sure there are libraries for menus and things like that, but I generally prefer to try to do it myself unless those libraries have a really good interface.
> I actually wouldn't call them "nice"
You're being polite... Those drop downs are hideous!
What's a good primer for understanding this? Given I have an EE degree, but only very basic quantum mechanics?
The post [and me, since I wrote it] recommends the video series Quantum Computing for the Determined [1].
If you're more familiar with physics than programming, Leonard Susskind's 'Quantum Mechanics: The Theoretical Minimum' [2] might work better. But I agree with Scott Aaronson that learning about quantum information before learning about quantum physics is easier than the opposite direction [3]:
> There are two ways to teach quantum mechanics. The first way -- which for most physicists today is still the only way -- follows the historical order in which the ideas were discovered. [...]
> Today, in the quantum information age, the fact that all the physicists had to learn quantum this way seems increasingly humorous. For example, I've had experts in quantum field theory -- people who've spent years calculating path integrals of mind-boggling complexity -- ask me to explain the Bell inequality to them. That's like Andrew Wiles asking me to explain the Pythagorean Theorem. [...]
> The second way [...] starts directly from the conceptual core -- namely, a certain generalization of probability theory to allow minus signs.
1: https://www.youtube.com/playlist?list=PL1826E60FD05B44E4
2: http://www.amazon.com/Quantum-Mechanics-Theoretical-Leonard-...
> But I agree with Scott Aaronson that learning about quantum information before learning about quantum physics is easier than the opposite direction.
I'm unconvinced that this is anything but Scott's personal opinion. Basically all teaching methodology advocates for concrete examples over abstract concepts. You can't get much more abstract than generalization of probability theory to allow minus signs.
It might work well for some people, and I'm happy it worked for you.
I don't really think the physical approach is any more concrete than Scott Aaronson's approach (at least in the way most people talk about concreteness wrt pedagogy). The point of having examples is to illustrate how general principles work in practice by specializing. You can do this just fine in quantum information/computation by discussing particular algorithms, problems, etc.
Frankly having taken both QC courses and QM courses, I found the physics-oriented exposition used a bunch of verbiage to phrase things in an experimental/physical way without really specializing the mathematical objects in any sense (eg, Stern-Gerlach experiments). That particular sort of concreteness can be helpful in other parts of physics, but physical intuition is weak to nonexistent in QM.
Anyway, I'm nowhere near a physicist so take my review with a grain of salt.
In the case of QM, I think the concrete physical cases are all counter-intuitive. They trigger the wrong ideas and confuse people instead of helping them, e.g. by having them focus on malformed questions like "is it a particle or is it a wave?".
Which is not to say that I think you should do two years of linear algebra before understanding how the heck it applies to reality. That would also be insane. I guess I just think that the first concrete case should be a qubit simulator. Something grounded that you can come back to and say "Well, what if I did this?" and get the right answer.
The IBM IQE simulator, that the article mentions (somewhat derisively), actually has a good tutorial on the topic. I found that IQE, since it is actually designed to run on an actual quantum computer, to be the most helpful thing I've done to understand how you would actually program a quantum computer. Most of the other simulators provide additional information that's not accessible on an actual quantum computer, making it harder to separate convenient "debugger" functionality from what is actually doable. Plus, by it's nature, IQE talks about the actual challenges and effects of noise on the output; and why quantum error correction is critical. Also, IQE gives numerous trivial example circuits, that for some reason helped things click for me.
A real quantum computer wins by a long shot in terms of coolness and difficulty to construct... But at this point there's no performance increase and they should provide the same results as a simulator. So I'll take the instantaneous results that a simulator provides until the hardware catches up.
It's mostly just complex linear algebra, finite dimensional. So, think eigenvectors, eigenvalues and operators. Measurements are essentially projection operators. And a little more tricky: the tensor product. The tensor product is the physicists way of saying "and". The Bloch sphere is a clever way of notating a vector. You may need density matrices (aka density operators), that's a bit more involved, but basically it allows you to take a probability distribution over vectors.
I don't know about a single primer, but you need an understanding of linear algebra, and the relevant operators.
Why does this site's header image seem to say "Bugs" (in near-white text) around (763,108)?
It's just a joke about bugs being subtle and hard to find despite hiding in plain sight. I'm kind of impressed you spotted it; I wasn't sure anyone ever would (it's harder to see on some monitors than others).
This looks great!
I noticed that custom gates were on your "work in progress" list. Does that include being able to reuse a circuit as a gate in another circuit? That's a killer feature for me. Being able to "abstract away" things like the Grover diffuse operation. That, or even copy & paste functionality to speed up designing those repetitions.
Yes, that's one of the things I plan to do [1].
(You can copy individual gate parts by holding shift as you grab them. I'm considering adding ctrl as a another modifier, meaning 'grab the whole column'. I understand that these modifiers are not discoverable.)
(At the moment, when I want to make a really large repetitive circuit, I copy the URL into a text editor and do my copy pasting there. I understand that it would be totally ridiculous to expect users to do that.)
Being able to copy & paste a column would speed up design. Certain quantum algorithms rely heavily on repeated application so not having a shorthand feels tedious.
Ideally, from my perspective as a user, I'd like some kind of selection box that I can drag over a portion of the circuit and duplicate everything highlighted.
PS: I like that you maintain the circuit in a URL linkable form. Very handy!
There's a few gates that you can only create by editing the URL ;).
Examples include the X-axis post-selection gates "|+⟩⟨+|" and "|-⟩⟨-|", some square-wave gates "X^⌈t⌉" and "X^⌈t-¼⌉" that were made redundant by the counting gate, the impossible universal-not gate "__unstable__UniversalNot" [1], and the error injection gate "__error__".
Very nice. I know nothing about quantum circuits, but just as a piece of software this is very cool.
My one criticism: there's something about the visual style of the interactive elements that makes them appear non-interactive until interacted with. The whole application initially looked like a static image to me before I started clicking around and fiddling with it.
Thanks, that's useful to know.
This is awesome. If you want a cool side project, you should definitely make this into a kerbal space program like game where you build quantum computers & optimization patterns. It would probably be super fun for you to build and also a fairly profitable venture given you have much of the codebase writeen.
Can someone do a back of the napkin calculation to compare the performance of a quantum simulator with the real deal?