Comments on: Bohring Fault-Tolerance http://dabacon.org/pontiff/?p=1028 Theoretical Musings Thu, 09 Sep 2010 14:06:56 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: How to Get Six Pack Fast http://dabacon.org/pontiff/?p=1028#comment-321857 How to Get Six Pack Fast Wed, 15 Apr 2009 13:55:01 +0000 http://dabacon.org/pontiff/?p=1028#comment-321857 My fellow on Orkut shared this link and I'm not dissapointed that I came here. My fellow on Orkut shared this link and I’m not dissapointed that I came here.

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Pisanha http://dabacon.org/pontiff/?p=1028#comment-119567 Pisanha Wed, 13 Sep 2006 03:29:55 +0000 http://dabacon.org/pontiff/?p=1028#comment-119567 % %

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Daniel Lidar http://dabacon.org/pontiff/?p=1028#comment-42384 Daniel Lidar Wed, 14 Sep 2005 18:36:13 +0000 http://dabacon.org/pontiff/?p=1028#comment-42384 If you want a preview of some of the details that will appear in our new version of the paper take a look at the <a href="http://www.research.ibm.com/quantuminfo/FTQC2005/presentations.html" rel="nofollow">IBM Fault Tolerance Workshop</a> talks. Slides 15+16 of my talk explain in some technical detail the issue with the WCL. If you want a preview of some of the details that will appear in our new version of the paper take a look at the IBM Fault Tolerance Workshop talks. Slides 15+16 of my talk explain in some technical detail the issue with the WCL.

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Daniel Lidar http://dabacon.org/pontiff/?p=1028#comment-42383 Daniel Lidar Wed, 14 Sep 2005 18:35:58 +0000 http://dabacon.org/pontiff/?p=1028#comment-42383 If you want a preview of some of the details that will appear in our new version of the paper take a look at the <a href="http://www.research.ibm.com/quantuminfo/FTQC2005/presentations.html" rel="nofollow">IBM Fault Tolerance Workshop</a> talks. Slides 15+16 of my talk explain in some technical detail the issue with the WCL. If you want a preview of some of the details that will appear in our new version of the paper take a look at the IBM Fault Tolerance Workshop talks. Slides 15+16 of my talk explain in some technical detail the issue with the WCL.

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Dave Bacon http://dabacon.org/pontiff/?p=1028#comment-42197 Dave Bacon Wed, 14 Sep 2005 00:04:27 +0000 http://dabacon.org/pontiff/?p=1028#comment-42197 I agree that one should not separate gate speed from decoherence: clearly if I try to run my computer too fast, all I will do is blow the system up. However, over wide ranges of parameters, I claim that this is a valid assumption. I guess I have to wait to see your new draft, but I don't see how your discussion of the degenerate case applies to the nondegenerate case. I agree that one should not separate gate speed from decoherence: clearly if I try to run my computer too fast, all I will do is blow the system up. However, over wide ranges of parameters, I claim that this is a valid assumption.

I guess I have to wait to see your new draft, but I don’t see how your discussion of the degenerate case applies to the nondegenerate case.

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Daniel Lidar http://dabacon.org/pontiff/?p=1028#comment-42195 Daniel Lidar Tue, 13 Sep 2005 23:46:15 +0000 http://dabacon.org/pontiff/?p=1028#comment-42195 I just noticed this new comment on our paper (unfortunately, almost a month after it was posted). In fact in section V.B (p.5) of the paper we discuss the case of quasi-degenerate qubits and replace the Bohr frequency by the Rabi frequency. The same WCL-type objection applies, just with a different energy scale (the Rabi frequency squared divided by the detuning). The statement made in our "Assumption 1" which emphasizes the Bohr frequency was made in this (somewhat misleading) form for simplicity. In the next version (stay tuned!) we will discuss this issue in much more detail and fix the confusing statement of Assumption 1. In short -- I fully agree with Dave that "Typically one works with gate speeds in implementations of quantum computers which are much slower than the Bohr frequency.", but this does not help in overcoming our objection, since the Rabi frequency sets a new energy scale for the WCL-type inconsistency. I do take issue with Dave's statement "In fault-tolerance, one needs gates which are fast in comparison to the decoherence/error rate of your quantum system", in the following sense: a decoherence rate, in the sense of an exponential decay rate, is a *derived* quantity, that comes out of a *Markovian* treatment (e.g., decoherence rate is 1/T_2). Therefore one cannot a priori compare gate speed (and let that be the Rabi frequency if we must) to exponential decoherence rate when one tries to derive consistency conditions. Why? Because gate speed is an input to the theory while decoherence rate is an output (so it's an apples to oranges comparison). In other words, one must first prove that a Markovian model is applicable before one can start talking about exponential decay rates. (On the other hand, if one has a good way to define a non-Markovian decoherence rate -- it will be non-exponential -- then there is no problem). I want to stress this point because one so often hears people comparing gate speed to (implicitly Markovian) decoherence rates, yet we showed in our paper that this is not always a properly defined notion. The Markovian limit is compatible only with adiabatic gates, with a timescale set by a relevant system energy scale (Bohr or Rabi). If you introduce fast gates you can't talk about Markovian decoherence rates. As for Sean Barrett's follow-up comment: please see Robert Alicki's reply to his comment in the original discussion. I just noticed this new comment on our paper (unfortunately, almost a month after it was posted). In fact in section V.B (p.5) of the paper we discuss the case of quasi-degenerate qubits and replace the Bohr frequency by the Rabi frequency. The same WCL-type objection applies, just with a different energy scale (the Rabi frequency squared divided by the detuning). The statement made in our “Assumption 1″ which emphasizes the Bohr frequency was made in this (somewhat misleading) form for simplicity. In the next version (stay tuned!) we will discuss this issue in much more detail and fix the confusing statement of Assumption 1.

In short — I fully agree with Dave that “Typically one works with gate speeds in implementations of quantum computers which are much slower than the Bohr frequency.”, but this does not help in overcoming our objection, since the Rabi frequency sets a new energy scale for the WCL-type inconsistency.

I do take issue with Dave’s statement “In fault-tolerance, one needs gates which are fast in comparison to the decoherence/error rate of your quantum system”, in the following sense: a decoherence rate, in the sense of an exponential decay rate, is a *derived* quantity, that comes out of a *Markovian* treatment (e.g., decoherence rate is 1/T_2). Therefore one cannot a priori compare gate speed (and let that be the Rabi frequency if we must) to exponential decoherence rate when one tries to derive consistency conditions. Why? Because gate speed is an input to the theory while decoherence rate is an output (so it’s an apples to oranges comparison). In other words, one must first prove that a Markovian model is applicable before one can start talking about exponential decay rates. (On the other hand, if one has a good way to define a non-Markovian decoherence rate — it will be non-exponential — then there is no problem). I want to stress this point because one so often hears people comparing gate speed to (implicitly Markovian) decoherence rates, yet we showed in our paper that this is not always a properly defined notion. The Markovian limit is compatible only with adiabatic gates, with a timescale set by a relevant system energy scale (Bohr or Rabi). If you introduce fast gates you can’t talk about Markovian decoherence rates.

As for Sean Barrett’s follow-up comment: please see Robert Alicki’s reply to his comment in the original discussion.

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Sean Barrett http://dabacon.org/pontiff/?p=1028#comment-37144 Sean Barrett Fri, 19 Aug 2005 07:49:04 +0000 http://dabacon.org/pontiff/?p=1028#comment-37144 I just wanted to point out that I think this is basically the same point I made when this paper first came up for discussion: http://dabacon.org/pontiff/?p=959#comment-20585 Essentially the gate speed can be the inverse of a rabi frequency, which can be much longer than the bath correllation time, but still short compared to the error rates. Hence we still have a markovian description for the errors, but can also have low error rates. If we turn off the driving field, the same markovian error model still holds, and we can now wait for the qubit to cool down, thus allowing ancilla preparation. I just wanted to point out that I think this is basically the same point I made when this paper first came up for discussion:

http://dabacon.org/pontiff/?p=959#comment-20585

Essentially the gate speed can be the inverse of a rabi frequency, which can be much longer than the bath correllation time, but still short compared to the error rates. Hence we still have a markovian description for the errors, but can also have low error rates. If we turn off the driving field, the same markovian error model still holds, and we can now wait for the qubit to cool down, thus allowing ancilla preparation.

Like or Dislike: Thumb up 0 Thumb down 0

]]>