Dumbledore is a side character. He needed to be got rid of, so neither Harry nor the reader would expect or hope for Dumbledore to show up at the last minute and save the day

There's technically six more hours of story time for a time-turned Dumbledore to show up, before going on to get trapped. He does mention that he's in two places during the mirror scene.

Dumbledore has previously stated that trying to fake situations goes terribly wrong, so there could be some interesting play with that concept and him being trapped by the mirror.

Sorry for getting that one wrong (I can only say that it's an unfortunately confusing name).

Your claim is that AGI programs have large min-length-plus-log-of-running-time complexity.

I think you need more justification for this being a useful analogy for how AGI is hard. Clarifications, to avoid mixing notions of problems getting harder as they get longer for any program with notions of single programs taking a lot of space to specify, would also be good.

Unless we're dealing with things like the Ackermann function or Ramsey numbers, the log-of-running-time component of KL complexity is going to be negligible compared to the space component.

Even in the case of search problems, this holds. Sure it takes 2^100 years to solve a huge 3-SAT problem, but that contribution of ~160 time-bits pales in comparison to the several kilobytes of space-bits you needed when encoding the input into the program.

Or suppose we're looking at the complexity of programs that find an AGI program. Presumably high, right? Except that the finder can bypass the time cost by pushing the search into the returned AGI's bootstrap code. Basically, you replace "run this" with "return this" at the start of the program and suddenly AGI-finding's KL complexity is just its K complexity. (see also: the P=NP algorithm that brute force finds programs that work, and so only "works" if P=NP)

I think what I'm getting at is: just use length plus running time, without the free logarithm. That will correctly capture the difficulty of search, instead of making it negligible compared to specifying the input.

Plus, after you move to non-logarithmed time complexity, you can more appropriately appeal to things like the no free lunch theorem and NP-completeness as weak justification for expecting AGI to be hard.

I would say cos is simpler than sin because its Taylor series has a factor of x knocked off.

In practice they tend to show up together, though. Often you can replace the pair with something like e^(i x), so maybe that should be considered the simplest.

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).

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.

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:

  |e>|O yes>/s^3 + i |right-toward-BS2>|O no>/2 - |e>|O no>/2 - |away>|O yes>/s^3 - |away>|O no>/s^2
  

• yellows go through the beam splitter, only interferes when O-ness agrees.

  |h>|O yes>/s^4 + i|g>|O yes>/s^4 + i |g>|O no>/s^3 - |h>|O no>/s^3 - |h>|O no>/s^3 - i|g>|O no>/s^3 - |away>|O yes>/s^3 - |away>|O no>/s^2
  |h>|O yes>/s^4 + i|g>|O yes>/s^4 - |h>|O no>/s - |away>|O yes>/s^3 - |away>|O no>/s^2
  ~ 6% h yes, 6% g yes, 50% h no, 13% away yes, 25% away no
  

CONDITIONAL upon O not having been present, |O yes> is equal to |O no> and there's more interference before going to percentages:

 |h>/s^4 + i|g>/s^4 - |h>/s - |away>/s^3 - |away>/s^2
|h>(1/s^4-1/s) + i|g>/s^4 - |away>(1/s^2 + 1/s^3)
~ 21% h, 6% g, 73% away

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.