No comment. :)
No comment. :)
We know that we have individual qubits that behave in a way dominated by quantum mechanics. (Figure 11 on page 11 in this paper would show straight-ish lines if they were effectively classical.) We know that they compute. (Slides 21, 41, and 45 in this presentation show histograms of how frequently random problems get solved correctly.)
We're working on showing that our qubits and pairs of qubits behave in a way dominated by quantum mechanics in a sense that's more related to how we solve problems with them. We're also trying out 8-qubit problems that would be difficult if our chips were completely classical and easier if they're completely quantum, so hopefully we see good results there too.
The purpose of this application is to estimate how long certain problems would take to solve using an adiabatic quantum computer similar to the ones we're making at D-Wave. Because we use real chip parameters, we can get real times in units of nanoseconds, but in order to get accurate results, the simulations it runs can be quite hefty.
This application has gone through large changes since it was started, improving and re-improving the results along the way, and hopefully we've now narrowed in on the settings that give the most solid results. It's certainly been a humbling learning experience, and brought to light just how amazingly difficult it is to accurately simulate adiabatic quantum computation.
The posted simulation results for 8 qubits through 96 qubits were done with settings that turned out to give much more accurate results than previously, which caught us by surprise. The 128's haven't been run with the new parameters yet. Based on this and several other major discrepancies we've found upon making improvements over the past year or two, we'll probably recommend these improvements to a few fellow researchers doing related work.
We're double-checking our latest results for 8 qubits through 48 qubits with more accurate, but much more time-consuming, settings to confirm that they're reasonably accurate with the settings we used last. If it continues to check out as it has for 8-32 qubits, we'll continue by running the 128's with the settings that are hopefully accurate enough while still feasible for 128-qubit simulations.
This app quite literally simulates a ball rolling around in a landscape specially-designed so that it accurately represents how our chips would act if they behaved based on classical physics instead of quantum physics. Ironically, this is quite important to demonstrating that our chips operate in a manner dominated by quantum-mechanical effects, since if we have predicted results based on classical physics and predicted results based on quantum physics, having real results consistently close to the quantum prediction and far from the classical prediction would be fairly solid evidence.
We'll also be using it to examine how a classical system would fair in bad cases known as "1st-order phase transitions", since contrary to initial expectations, a few small cases suggest that a quantum computer may do much better than classical even in these bad scenarios.
We're simulating several experiments we're trying on a couple of our chips that, based on our earlier experiments, should give the clearest distinction between how a classical computer would behave and how a quantum computer would behave, given the constraints of what we can measure on our chips.
When we've gotten the data we need from the classical simulations, quantum simulations (done locally, not the AQUA app), and chips, organized it in a way that's easy to compare, and ironed out the unexpected issues between here and there. :)
This application is similar to the AQUA app, but with an extra set of inputs that could be implemented in future chips. The goal is to try out new algorithms that can eliminate bad cases by tuning these inputs dynamically.
In particular, the "1st-order phase transitions" mentioned above can be examined in great detail.
There've been several publications in recent months arguing that these are very bad cases for adiabatic quantum computers, and that they occur often for large problems, but only one paper so far looked at eliminating them. That one paper concluded that randomly setting these extra inputs can eliminate one bad case, so we're looking at strategically setting the inputs to eliminate billions of bad cases all occuring at once.
Some problems that are unfathomably bad for the default input values can be made trivial without much effort.
The Fokker-Planck and AQUA simulations are higher priority right now (Mar. 1, 2010). Also, the IQUANA simulations require much more preprocessing and management overhead than the other apps, so it's difficult to keep its queue from emptying even when it's the priority.