Question

想知道使用某些引用键索引应用程序的每个可能状态是否有用......

意思是，假设我们有一个启动的程序，只有很多可能的结果，比如8。

但如果通过逐步执行更多逻辑状态来获得每个结果，并且在每个分支之间被认为是状态并且映射到密钥。

在大型程序中可能需要大量内存，但如果我们可以直接访问密钥（密钥可以基于逻辑的时间或深度），那么我们可以立即遍历任何可能的情况而无需启动整个过程再次提供新数据。

将其想象为一棵树，其中没有孩子的节点是最终结果，节点与其父母或孩子之间的每个分支都是“状态”，每个分支的键入方式不同。因此，虽然只有8个叶子，或者该过程的最终结果，但可能存在许多“状态”，这取决于在用完孩子之前逻辑在树上的深度。

也许是为了模拟，但需要大量的记忆。

Answer 1

这不可能解决一般程序。暂停问题证明无法确定程序是否会停止。确定给定状态是否可能的问题可以归结为暂停问题，因此也无法解决。

Answer 2

我认为这种做法对任何事情都是完全棘手的。

作为一个搜索问题，它太大了。如果我们假设每个州可以导致10个结果（虽然我认为这个数字真的很低），那么只需要前面20步，我们现在必须跟踪2000亿个可能性。

请记住，循环中的每一步都算作分支点。因此，如果我们的代码如下所示：

for (int i=0; i < 100; i++)
    some_function();

然后可能的状态数是（some_function内的分支数）^ 100

Answer 3

虽然Josh是正确的，由于它的含糊不清，你无法回答这个问题最自由的版本，如果你对你的场景有一些限制，你可以回答它。您的计划状态与商业实体的状态之间存在很大差异。

例如，假设您有一个由DFA（状态机）定义的面向工作流的应用程序。然后，您实际上可以将该DFA中的给定点与某种ID相关联。

所以是的，它易于处理，但并非没有限制。

Answer 4

这是在功能级别完成的;这是一种名为memoization的技术。

Answer 5

研究kripke结构和模态逻辑。这是建模程序中采用的方法。我忘了使用这种方法的经典系统是什么。

Answer 6

Ryan，答案肯定是肯定的。

与第一个答案相反，暂停问题并不能证明什么。事实上，Ryan，你所建议的证明停止问题错误不适用于真正的数字计算机，我之前用这个例子作为它的证据。

在确定性数字系统（即在真实数字硬件上运行的程序）中，可能状态的数量是有限的，因此所有可能的状态都是可枚举的。

哈希所需的确切内存量为：

<强> (2)*(program state size)*(number of initial states)

初始状态将是您的哈希键，最终状态将是哈希值，然后您将为每个初始状态设置键/值对。

对于操作系统，“程序状态大小”为2 ^（所有系统设备的内存总量为千兆位）。显然，如此庞大的通用程序需要一个不切实际的内存来进行散列，并且无论如何都不会有用，因为系统是自引用/不可简化的复杂（即下一个用户输入取决于以前的系统输出）。 p>

<强>解释

这非常有用，因为如果您索引每个可能的初始状态并将其与终止状态相关联，您将有效地将任何程序的运行时间归零！任何为零我的意思是非常快的O（1）运行时间 - 查找终止状态所花费的时间（如果它终止）。

从所有可能状态开始运行程序将提供一种显示周期的状态图。 停止问题因此得到解决，因为在任何可能的初始状态下，只有三个（实际上有四个崩溃到三个）可能性：

程序将在耗尽所有可能的状态之前重新进入先前遇到的状态（从初始状态开始），因此逻辑上会永远循环。
程序在有机会重新进入先前遇到的状态或耗尽所有可能的状态（从初始状态开始）之后达到标识为“终止”的状态。
或4.最简单的程序将从初始状态开始，将完全输入所有可能的状态一次，然后别无选择，只能（3）停止或（4）重新输入先前遇到的状态并永远循环

for（int i = 0; true; i ++）; //我将达到最大值，翻转回零，此时它将重新进入初始状态

所以，基本上，您的索引可以这样描述：

换句话说，对于每个初始状态，程序要么达到终止状态，要么重新进入自初始状态以来已经遇到的状态并且无休止地循环。

因此，对于在确定性数字硬件上运行的任何程序，绝对可能（但通常不实用）来确定其所有状态以及它是否会永久停止或循环。

除了强制任何程序的运行时间进行O（1）操作外，捕获状态的其他用途包括游戏控制台模拟器中的保存状态功能和计算机的休眠功能（尽管不是完美的状态恢复，因为某些系统内存必须用于恢复状态的代码，并且可能永远不会存储某些内存（例如GPU内存）。）

这证明了任何程序都可以用哈希表来表示。任何程序都可以由初始到最终的状态转换映射表示。 所有程序都可以简化为具有大量内存占用的大功能！