feat: add more solomonoff changes

blog/2023/03/01/computable-solomoff/index.md

@@ -28,6 +28,33 @@ To fix this, in step 2, we can require that there be not only one turing machine
 
 Interestingly, that scheme also suggests that there is a tradeoff between arriving at the correct hypothesis as fast as possible—in which case we would just implement the first scheme at full speed—and producing accurate probabilities—in which case it seems like we would have to use a tweak
 
+### A distracting epicycle: dealing with Turing machines that take too long or do not halt.
+
+When thinking about Turing machines, one might consider one particular model, e.g., valid C programs. But in that case, it is easy to consider programs that do not halt, like:[^2]
+[^2]: Readers might find it amusing to run gcc loop.c and check it
+
+```
+void main(){
+  while(1){
+    ;
+  }
+}
+```
+
+But then in step 2 of our scheme, we never get to see what bits this program outputs, because it never outputs any bits.
+
+This can easily be fixed as follows:
+
+1. Start with a finite set of live turing machines, \(\{T_0, ..., T_n\}\), a compute budget \( s \) and an empty cache of programs which take too long \( C =\{\} \)
+1. Run each \( T_i \) for \( s \) seconds. 
+1. If none of them predict your trail bits, \( (B_0, ..., B_m) \), within the given compute budget: 
+  -  eliminate the ones who make incorrect predictions.
+  -  keep track of programs which didn't output anything in the cache.
+  -  attempt to compute the first \( m \) steps of Turing machine \(T_{n+1} \) with \( s \) seconds of compute. If it makes correct predictions, keep it in the set of live machines, otherwise move it to the cache.
+  -  increase the compute budget to \( s + 1 \) and run each machine in the cache for one additional second
+  -  Repeat step 2 until you have one program which has predicted past bits within your compute budget. Eventually this program must exist, since the Turing machine which is producing your trail of bits is by construction computable and non-halting.\footnote{Or at least, it hasn't halted before producing the number of bits that you have seen so far.}
+1. Observe the next bit, purge the machines from your set which don't predict it. If none predict it, GOTO 2.
+
 <p>
   <section id='isso-thread'>
   <noscript>Javascript needs to be activated to view comments.</noscript>

blog/2023/03/01/computable-solomoff/src/loop.c

@@ -0,0 +1,5 @@
+int main(){
+  while(1){
+		;
+	}
+}

blog/2023/03/01/computable-solomoff/src/main.tex

@@ -6,7 +6,6 @@
  \def\@oddfoot{\centerline{\thepage}}%
  \let\@evenfoot\@oddfoot}
 
-%% The amssymb package provides various useful mathematical symbols
 
 \begin{document}
 
@@ -68,17 +67,36 @@ Interestingly, that scheme also suggests that there is a tradeoff between arrivi
 
 Note that a downside of the procedures outlined above is that at the point we arrive at the correct hypothesis, we don't know that this is the case.
 
-\section{An irrelevant epicycle: dealing with Turing machines that take too long or do not halt.}
+\section{An distracting epicycle: dealing with Turing machines that take too long or do not halt.}
 
-When thinking about Turing machines, one might consider one particular model, e.g., valid C programs. But in that case, it is easy to consider 
+When thinking about Turing machines, one might consider one particular model, e.g., valid C programs. But in that case, it is easy to consider programs that do not halt, like:\footnote{Readers might find it amusing to run gcc loop.c and check it}:
 
 \begin{verbatim}
 void main(){
-  while(true){
-	}
+  while(1){
+    ;
+  }
 }
 \end{verbatim}
 
+But then in step 2 of our scheme, we never get to see what bits this program outputs, because it never outputs any bits.
+
+This can easily be fixed as follows:
+
+\begin{enumerate}
+	\item Start with a finite set of live turing machines, $\{T_0, ..., T_n\}$, a compute budget $s$ and an empty cache of programs which take too long $C =\{\}$
+	\item Run each $T_i$ for $s$ seconds. 
+	\item If none of them predict your trail bits, $(B_0, ..., B_m)$, within the given compute budget: 
+		\begin{enumerate}
+		   \item eliminate the ones who make incorrect predictions.
+			 \item keep track of programs which didn't output anything in the cache.
+			 \item attempt to compute the first $m$ steps of Turing machine $T_{n+1}$ with $s$ seconds of compute. If it makes correct predictions, keep it in the set of live machines, otherwise move it to the cache.
+			 \item increase the compute budget to $s + 1$ and run each machine in the cache for one additional second
+			 \item Repeat steps 2-3 until you have one program which has predicted past bits within your compute budget. Eventually this program must exist, since the Turing machine which is producing your trail of bits is by construction computable and non-halting.\footnote{Or at least, it hasn't halted before producing the number of bits that you have seen so far.}
+			\item 
+		\end{enumerate}
+	\item Observe the next bit, purge the machines from your set which don't predict it. If none predict it, GOTO 2.
+\end{enumerate}
 
 \end{document}
 

blog/2023/03/01/computable-solomoff/src/test.md

@@ -0,0 +1,29 @@
+\section{An distracting epicycle: dealing with Turing machines that take too long or do not halt.}
+
+When thinking about Turing machines, one might consider one particular model, e.g., valid C programs. But in that case, it is easy to consider programs that do not halt, like:\footnote{Readers might find it amusing to run gcc loop.c and check it}:
+
+\begin{verbatim}
+void main(){
+  while(1){
+    ;
+  }
+}
+\end{verbatim}
+
+But then in step 2 of our scheme, we never get to see what bits this program outputs, because it never outputs any bits.
+
+This can easily be fixed as follows:
+
+\begin{enumerate}
+	\item Start with a finite set of live turing machines, $\{T_0, ..., T_n\}$, a compute budget $s$ and an empty cache of programs which take too long $C =\{\}$
+	\item Run each $T_i$ for $s$ seconds. 
+	\item If none of them predict your trail bits, $(B_0, ..., B_m)$, within the given compute budget: 
+		\begin{enumerate}
+		   \item eliminate the ones who make incorrect predictions.
+			 \item keep track of programs which didn't output anything in the cache.
+			 \item attempt to compute the first $m$ steps of Turing machine $T_{n+1}$ with $s$ seconds of compute. If it makes correct predictions, keep it in the set of live machines, otherwise move it to the cache.
+			 \item increase the compute budget to $s + 1$ and run each machine in the cache for one additional second
+			 \item Repeat step 2 until you have one program which has predicted past bits within your compute budget. Eventually this program must exist, since the Turing machine which is producing your trail of bits is by construction computable and non-halting.\footnote{Or at least, it hasn't halted before producing the number of bits that you have seen so far.}
+			\item 
+		\end{enumerate}
+	\item Observe the next bit, purge the machines from your set which don't predict it. If none predict it, GOTO 2.