It's just a coincidence.
I can speak from personal recollection on the Google side. Google originally intended to use a 72 qubit chip (Bristlecone) where qubits were essentially directly connected to each other. They then switched to an architecture where qubits were connected indirectly via a coupler. The coupler requires a control line, so this increased ...
They have different error rates because they are two different physical devices! This relates to the manufacturing processes of these chips. Every device is unique and will have its own fingerprint meaning its own error rate. Of course this is not something that manufactures do on purpose, but a side effect of making these qubit devices. It’s very difficult ...
The choice of gates is entirely dependent on the types of interactions that occur in the different architectures. The cross resonance gate used by IBM generates the ZX interaction you want (plus other stuff) that leads to a CNOT. Trapped ions have XX type interactions that give rise to Molmer Sorensen gates. For single qubit gates it depends on what driving ...
No output shows for your code as you have a line underneath the call to plot_histogram(). This should be the last line of the section in the Jupyter notebook if you would like the image to be displayed.
I was able to run your code by removing the final line (print(counts)) and it displayed the histogram below.
The Q-Object not valid error you received is caused by the amount of shots you set. The max shots allowed is 8192. Since the amount of shots you set (16384) is greater than the max amount of shots allowed, you get that error.
The TranspilerError is caused by the second format for layout. When I tested your code with the second layout, I received this error ...
I was recently looking for a similar solution. Hope this helps.
job = execute(qc, backend=backend, shots=1024)
results = job.result()
You can also check all the values stored in result as it is a dictionary by printing it:
Here you can check for all the information that is available within the dictionary and you ...
My guess is that this is an example of co-opetition, i.e. collaborative competition. Number of qubits is just a single characteristic of a quantum processor, but there are a lot more, like tolerance, topology, etc. Also this characteristic is the only one that most people understand. Thus it's not reasonable to put all the resources on the increasing just ...
To simulate a 3D material, the material's structure will need to be somewhat understood. That way the structure can be mapped to the qubit connectivity. Notice in this tutorial the qubits and their connections to each other are represented in graphs. The 3D material to be simulated can be put into a graph that will then be mapped to the qubit graph and the ...
Well actually when looking at the source code, the construct_circuit method:
quantum register where the sequential QFT is performed
self._up_qreg = QuantumRegister(2 * self._n, name='up')
# quantum register where the multiplications are made
self._down_qreg = QuantumRegister(self._n, name='down')
# auxiliary quantum register used in ...
I would add that thermic noise, radiocative background (mainly cosmic rays) can play role in different error rate as those noise sources are different for each quantum processor.
Moreover, as a user of IBM Q, you probably know that quantum processors are sometimes under maintenance. Since each processor is maintained in different time, their runtime is ...
You might find some examples in this two-year-old question :)
To the best of my knowledge, the most recent work that implements some code on IBMQ's quantum devices is about the repetition code (see the textbook or the paper). If you only want to do the simulation, there should be no problem to take a further step towards more advanced codes. But if you mean ...
The could be a problem, but it depends on how you're realising your qubits. Some realisations are configured so that $E_0=E_1$, and then there's no problem.
There is (at least from the theoretical perspective) a simple fix: if you're supposed to be waiting a time $t$, then, instead:
wait time $t/2$
apply bit flip
wait time $t/2$
apply bit flip.
It is always difficult to force classical algorithms to quantum devices. And this is maybe a signal that quantum algorithms should be something different and new. Actually, quantum systems have unique properties like entanglement, that classical systems don't have.
However, look at the following paper for a study on the relation between fuzzy and quantum ...
There is no hub simply called ibm-q. I think what you are meaning to do is
provider = IBMQ.get_provider(). What you put in the brackets is the name of the hub, for example if your school was a registered hub you might have something to write in there but most users will leave the brackets blank. After this you can do backend = provider.get_backend(...
I'm not sure what had caused the problem but I was able to solve it and most likely know what the problem was.
Consider these two lines from my code above:
job_exp = execute(qc, backend = backend, shots = 8192)
exp_result = job_exp.result()
Problem with the above lines is that we are not waiting for the actual quantum device to compute and send over the ...
EDIT: I believe this is solved in @IEIrodov's answer below.
I'm not sure what's causing the issue, but based on similar issues on the qiskit slack channel, I don't think it's something you're doing.
As a workaround, try running:
exp_result = job_exp.result()
exp_measurement_result = exp_result.get_counts()
I also came across with the same issue. However when I added my account token as follows, it worked.
token = 'Your token'
provider = IBMQ.load_account()
device = provider.get_backend('ibmq_16_melbourne')
You can get your IBM Q token via : https://quantum-computing.ibm.com/account
Hope this helped, let me know if it didn't.
Both IBM and Google unveiled 53-qubit processors. At this time, only Google published performance metrics such as 1- and 2-qubit gate errors. Until IBM publishes similar metrics we simply cannot even tell whether Google's processor outperforms IBM's.
What we can tell is that the connectivity of the two processors is different - Google's Sycamore processor ...
I'm sure that this has something to do with quantum decoherence or "noise" which is caused when more qubits are added. It's likely that they are both at the frontlines of research so 53 qubits are the best that they can do given the hardware that they have access to. As they add more qubits it gets tougher to compute and prompts them to find some suitable ...