Okay, I’ve gone through all the work of checking if this actually works as a bomb tester. What I found is that you can use the camera to remove more dud bombs than live bombs, but it does worse than the trivial bomb tester.
So I was wrong when I said you could use it as a drop-in replacement. You have to be aware that you’re getting less evidence per trial, and so the tradeoffs for doing another pass are higher (since you lose half of the good bombs with every pass with both the camera and the trivial bomb tester; better bomb testers can lose fewer bombs per pass). But it can be repurposed into a bomb tester.
I do still think that understanding the bomb tester is a stepping stone towards understanding the camera.
Anyways, on to the clunky analysis.
Here’s the (simpler version of the) interferometer diagram from the paper:
Here’s my interpretation of the state progression:
Start
|green on left-toward-BS1>
Beam splitter is hit. s = sqrt(2)
|green on a>/s + i |green on left-downward-path>/s
non-linear crystal 1 is hit, splits green into (red + yellow) / s
|red on a>/2 + |yellow on a>/2 + i |green on left-downward-path>/s
hit frequency-specific-mirror D1 and bottom-left mirror
i |red on d>/s^2 + |yellow on c>/s^2 - |green on b>/s
interaction with O, which is either a detector or nothing at all
i |red on d>|O yes>/s^2 + |yellow on c>|O no>/s^2 - |green on b>|O no>/s
hit frequency-specific-mirror D2, and top-right mirror
-|red on b>|O yes>/s^2 + i |yellow on right-toward-BS2>|O no>/s^2 - |green on b>|O no>/s
hit non-linear crystal 2, which acts like NL1 for green but also splits
red into red-yellow. Not sure how this one is unitary… probably a green →
[1, 1] while red → [1, −1] thing so that’s what I’ll do:
-|red on f>|O yes>/s^3 + |yellow on e>|O yes>/s^3 + i |yellow on right-toward-BS2>|O no>/s^2 - |red on f>|O no>/s^2 - |yellow on e>|O no>/s^2
red is reflected away; call those “away” and stop caring about color:
Ignoring the fact that I probably made a half-dozen repairable sign errors, what happens if we use this as a bomb tester on 200 bombs where a hundred of them are live but we don’t know which? Approximately:
6 exploded bombs that triggered h
21 dud bombs that triggered h
50 live bombs that triggered h
6 exploded bombs that triggered g
6 dud bombs that triggered g
0 live bombs that triggered g
13 exploded bombs that triggered nothing
25 live bombs that triggered nothing
73 dud bombs that triggered nothing
So, of the bombs that triggered h but did not explode, 50⁄71 are live. Of the bombs that triggered g but did not explode, none are live. Of the bombs that triggered nothing but did not explode, 25⁄98 are live.
If we keep only the bombs that triggered h, we have raised our proportion of good unexploded bombs from 50% to 70%. In doing so, we lost half of the good bombs. We can repeat the test again to gain more evidence, and each time we’ll lose half the good bombs, but we’ll lose proportionally more of the dud bombs.
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.
Okay, I’ve gone through all the work of checking if this actually works as a bomb tester. What I found is that you can use the camera to remove more dud bombs than live bombs, but it does worse than the trivial bomb tester.
So I was wrong when I said you could use it as a drop-in replacement. You have to be aware that you’re getting less evidence per trial, and so the tradeoffs for doing another pass are higher (since you lose half of the good bombs with every pass with both the camera and the trivial bomb tester; better bomb testers can lose fewer bombs per pass). But it can be repurposed into a bomb tester.
I do still think that understanding the bomb tester is a stepping stone towards understanding the camera.
Anyways, on to the clunky analysis.
Here’s the (simpler version of the) interferometer diagram from the paper:
Here’s my interpretation of the state progression:
Start
Beam splitter is hit. s = sqrt(2)
non-linear crystal 1 is hit, splits green into (red + yellow) / s
hit frequency-specific-mirror D1 and bottom-left mirror
interaction with O, which is either a detector or nothing at all
hit frequency-specific-mirror D2, and top-right mirror
hit non-linear crystal 2, which acts like NL1 for green but also splits red into red-yellow. Not sure how this one is unitary… probably a green → [1, 1] while red → [1, −1] thing so that’s what I’ll do:
red is reflected away; call those “away” and stop caring about color:
yellows go through the beam splitter, only interferes when O-ness agrees.
CONDITIONAL upon O not having been present, |O yes> is equal to |O no> and there’s more interference before going to percentages:
Ignoring the fact that I probably made a half-dozen repairable sign errors, what happens if we use this as a bomb tester on 200 bombs where a hundred of them are live but we don’t know which? Approximately:
6 exploded bombs that triggered h
21 dud bombs that triggered h
50 live bombs that triggered h
6 exploded bombs that triggered g
6 dud bombs that triggered g
0 live bombs that triggered g
13 exploded bombs that triggered nothing
25 live bombs that triggered nothing
73 dud bombs that triggered nothing
So, of the bombs that triggered h but did not explode, 50⁄71 are live. Of the bombs that triggered g but did not explode, none are live. Of the bombs that triggered nothing but did not explode, 25⁄98 are live.
If we keep only the bombs that triggered h, we have raised our proportion of good unexploded bombs from 50% to 70%. In doing so, we lost half of the good bombs. We can repeat the test again to gain more evidence, and each time we’ll lose half the good bombs, but we’ll lose proportionally more of the dud bombs.
Therefore the camera works as a bomb tester.
I do not see a way that a live bomb can trigger nothing, or for an exploded bomb to trigger either g or h.
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.