Kolmogorov 复杂度逼近算法答案

【问题标题】：Kolmogorov Complexity Approximation AlgorithmKolmogorov 复杂度逼近算法
【发布时间】：2023-03-29 22:07:01
【问题描述】：

我正在寻找一种可以计算给定输入字符串的 Kolmogorov 复杂度近似值的算法。因此，如果 K 是字符串 S 的 Kolmogorov 复杂度，并且 t 代表时间，那么该函数的行为将如下所示..limit(t->inf)[K_approx(t,S)] = K.

【问题讨论】：

对于不熟悉该主题的人来说，字符串的 Kolmogorov 复杂度本质上是“生成字符串的最短程序的长度”。例如，可以使用 J 编程语言 (see here) 以 8 个字符 (*/~1+i.9) 生成 9x9 乘法表。由此，您可以说 9x9 乘法表的 Kolmogorov 复杂度相对于 J 编程语言为 8 或更低。
如果你想正式证明某事，你必须独立于（完全不考虑）用来近似它的方法来编写你的证明。如果您只是在寻找乐趣，不妨试试数据压缩算法？
不，我不是在寻找证据。我正在寻找满足上述属性的算法。我还没有找到，我想知道是否有人已经这样做了。我不知道任何数据压缩算法，只要有足够的时间，原则上可以找到确切的 Kolmogorov 复杂度。乍一看，由于您总是使用有限字符串，因此对所有可能的图灵机进行枚举搜索可能会起作用……但是问题可能无法确定。我正在为机器学习应用寻找这样的算法。
现在机器学习应用主要集中在压缩感知、模型缩减算法等，KC太理论化了。
似乎是功课......但乔伊亚当斯是对的。你有你的答案。

标签： algorithm theory complexity-theory

【解决方案1】：

理论上，当运行时间接近无穷大时，程序可以收敛于其输入字符串的 Kolmogorov 复杂度。它可以通过并行运行每个可能的程序来工作，即输入字符串的长度或更短。当找到给定长度的程序时，该长度被标识为现在已知的最小长度，并被打印，并且不再尝试 >= 该长度的程序。该算法将（很可能）永远运行，打印越来越短的长度，在无限时间的情况下收敛到确切的 Kolmogorov 复杂度。

当然，运行指数级的程序是非常棘手的。更有效的算法是发布code golf on StackOverflow。一些缺点：

可能需要几天时间才能找到好的结果。
它使用了大量我们最宝贵的计算资源，造成了数千美元的生产力损失。
随着资源被转移到other computations，结果的生成频率随着时间的推移而降低。
算法 terminates prematurely 用于许多输入，这意味着它通常不起作用。

【讨论】：

或者你很快就会遇到一个永远运行的程序，你无法决定是停止它还是让它再运行几秒钟（几十年）。
@rwong：是的，这就是你并行运行它们的原因。对于许多似乎永远运行的程序，它们可以继续运行，直到找到更短的解决方案（如果有的话）。
我想在函数中添加另一个参数来指定图灵机的最大长度是合理的。所以我们可以有一个函数，它可能具有这样的属性？限制(t->inf)[限制(T_max->inf)[K_approx(t,S,T_max)]] = K
我想到了蠕虫......（对于那些不熟悉代码高尔夫的人：meta.stackexchange.com/questions/20736/…）
@Tony: 是空间限制，还是程序长度限制？您只需要有限的时间来找到给定运行时间的最短程序（因为它们都会终止，呵呵）。不太明显的是，您只需要有限的时间来使用有限的空间找到最短的程序。后者是正确的，因为停止问题对于在有限空间中运行的程序是可判定的（想想看）。因此，您可以限制为运行时间 -> 无限或空间 -> 无限。你不需要两者都做。

【解决方案2】：

用于 Kolmogorov 复杂性的 wikipedia page 在“基本结果”部分下有一个名为“Kolmogorov 复杂性的不可计算性”的小节。这不是您可以计算的基本度量，甚至不是有效的近似值。

毫无疑问，有更好的方法可以实现您想要的。如果您想要测量随机性，您可以尝试二元熵函数。一种标准算法的可压缩性也可能符合要求。

【讨论】：

Wiki 文章甚至没有在任何地方提到“近似高效”这个短语。没有问计算字符串的 KC 的问题。这是不确定的..故事的结尾。我正在寻找的只是一个函数，它可以通过给予它更多的时间和空间资源来产生越来越好的近似值。
@Tony：您的算法没有完全指定。我不确定您计划如何使用每个可能的输入字符串测试每个可能的图灵机，但即使您可以以某种有意义的方式执行此操作，时间成本也会成倍增加。不管这个理论看起来多么好，它在实践中并不适合你。
@Rob，该函数只接受1个字符串作为输入“S:String”，并且只会测试大小为TMax的图灵机。所以我们没有测试所有的图灵机，因此无法得到输入字符串的准确 KC。
@Tony - 我认为小型随机生成的图灵机不会成为绝大多数输入字符串的解决方案（即有效的压缩器）。
@斯蒂芬。车床不是随机生成的。它们将被列举。只有在确定算法时才能考虑任何优化概念。

【解决方案3】：

我认为这可能有效？如果有人看到错误，请指出。

function KApprox(S:string,t:integer,TapeSizeMax:integer) : Turing Machine of size k
  begin

    // An abstract data type that represents a turing machine of size k
    var TM(k:integer) : Turing Machine of size k;
    var TMSmallest(k:integer) : Turing Machine of size k;  

    var j : integer;
    var i : integer;

    for (j = t to 0 step -1) // reduce the time counter by 1
      begin
       for (i = TMax to 1 step -1) // go to the next smaller size of TM
         begin
          foreach (TM(i)) // enumerate each TM of size i
             begin 
               if (TM(i).halt(TapeSizeMax) == true) and (TM(i).output() == S) then
                 begin
                   if (sizeof(TM(i)) < sizeof(TMSmallest(i))) then
                      TMSmallest(i): = TM(i);
                 end;
             end;
         end;
      end;      
    return TMSmallest;
 end;

【讨论】：

我认为致命的缺陷是TM[i].output() 可能永远不会回来。
我认为这将解决停止问题。
现在的问题是没有halts()函数这样的东西。您可以编写一个适用于某些机器的程序，但不能适用于所有机器。
@ok，所以我指定了暂停功能仅适用于大小为 TMax 的机器。因此 .halts(TMax)
但是您不能为 TMax > 4 编写halts() 函数。参见mathworld.wolfram.com/HaltingProblem.html

【解决方案4】：

看起来 Ray Solomonoff 在这个领域做了很多工作。

Publications of Ray Solomonoff

Inductive Inference Theory - A Unified Approach to Problems in Pattern Recognition and Artificial Intelligence.

Does Algorithmic Probability Solve the Problem of Induction?

【讨论】：

【解决方案5】：

我注意到的第一个问题是“Kolmogorov 复杂性”没有得到很好的定义。这在某种程度上取决于如何表示程序的选择。因此，您需要做的第一件事是修复程序的一些编码（例如，Joey Adams 的程序用 J 编写的规范）。

一旦你有了编码，你正在寻找的算法就很简单了。请参阅 Joey 的回答。

但情况比不得不运行成倍增长的程序还要糟糕。这些程序中的每一个都可以按照您的想象运行（从技术上讲：作为函数输入大小的运行时间可能比任何递归函数增长得更快）。更重要的是，一些最短的程序可能是运行时间最长的程序。因此，虽然随着时间的推移，并行方法会接近正确的值，但它会以难以想象的缓慢速度完成。

您可以提前停止程序，认为此时的近似值已经足够好。但是，您通常不知道该近似值有多好。事实上，有些定理表明你永远无法知道。

所以简短的回答是“简单，只需使用 Joey 的算法”，但无论从实用性衡量，答案都是“你没有机会”。正如 rwong 所建议的，您最好只使用重型压缩算法。

【讨论】：