A live bomb triggers nothing when the photon takes the left leg (50% chance), gets converted into red instead of yellow (50% chance), and gets reflected out.
An exploded bomb triggers g or h because I assumed the photon kept going. That is to say, I modeled the bomb as a controlled-not gate with the photon passing by being the control. This has no effect on how well the bomb tester works, since we only care about the ratio of live-to-dud bombs for each outcome. You can collapse all the exploded-and-triggered cases into just “exploded” if you like.
Hrm… reading the paper, it does look like NL1 goes from |a> to |cd> instead of |c> + |d>, This is going to move all the numbers around, but you’ll still find that it works as a bomb detector. The yellow coming out of the left non-interacting-with-bomb path only interferes with the yellow from the right-and-mid path when the bomb is a dud.
Just to be sure, I tried my hand at converting it into a logic circuit. Here’s what I get:
Having it create both the red and yellow photon, instead of either-or, seems to have improved its function as a bomb tester back up to the level of the naive bomb tester. Half of the live bombs will explode, a quarter will trigger g, and the other quarter will trigger h. None of the dud bombs will explode or trigger g; all of them trigger h. Anytime g triggers, you’ve found a live bomb without exploding it.
If you’re going to point out another minor flaw, please actually go through the analysis to show it stops working as a bomb tester. It’s frustrating for the workload to be so asymmetric, and hints at motivated stopping (and I suppose motivated continuing for me).
I never said it wouldn’t. I agreed up front that this would detect a bomb without interacting with it 50% of the time. It’s a minimally-functional bomb-tester, and the way you would optimize it is by layering the original bomb-testing apparatus over this apparatus. The two effects are pretty much completely orthogonal.
ETA: Did you just downvote my half of this whole comment chain? Am I actually wrong? If not, it appears that you’re frustrated that I’m reaching the right answer much more easily than you, which just seems petty.
Also, these are not nit-picks. You were setting the problem up entirely wrong.
A live bomb triggers nothing when the photon takes the left leg (50% chance), gets converted into red instead of yellow (50% chance), and gets reflected out.
An exploded bomb triggers g or h because I assumed the photon kept going. That is to say, I modeled the bomb as a controlled-not gate with the photon passing by being the control. This has no effect on how well the bomb tester works, since we only care about the ratio of live-to-dud bombs for each outcome. You can collapse all the exploded-and-triggered cases into just “exploded” if you like.
The photon does not get converted into red OR yellow. It gets converted into red AND yellow.
Hrm… reading the paper, it does look like NL1 goes from |a> to |cd> instead of |c> + |d>, This is going to move all the numbers around, but you’ll still find that it works as a bomb detector. The yellow coming out of the left non-interacting-with-bomb path only interferes with the yellow from the right-and-mid path when the bomb is a dud.
Just to be sure, I tried my hand at converting it into a logic circuit. Here’s what I get:
Having it create both the red and yellow photon, instead of either-or, seems to have improved its function as a bomb tester back up to the level of the naive bomb tester. Half of the live bombs will explode, a quarter will trigger g, and the other quarter will trigger h. None of the dud bombs will explode or trigger g; all of them trigger h. Anytime g triggers, you’ve found a live bomb without exploding it.
If you’re going to point out another minor flaw, please actually go through the analysis to show it stops working as a bomb tester. It’s frustrating for the workload to be so asymmetric, and hints at motivated stopping (and I suppose motivated continuing for me).
I never said it wouldn’t. I agreed up front that this would detect a bomb without interacting with it 50% of the time. It’s a minimally-functional bomb-tester, and the way you would optimize it is by layering the original bomb-testing apparatus over this apparatus. The two effects are pretty much completely orthogonal.
ETA: Did you just downvote my half of this whole comment chain? Am I actually wrong? If not, it appears that you’re frustrated that I’m reaching the right answer much more easily than you, which just seems petty.
Also, these are not nit-picks. You were setting the problem up entirely wrong.