想知道使用一些参考键索引应用程序的每个可能状态是否有用......
意思是，假设我们有一个启动的程序，只有这么多可能的结果，比如 8。
但是如果每个结果都是通过更多的逻辑状态来获得的，并且在每个分支之间被认为是一个状态并映射到一个键。
在大型程序中可能会占用大量内存，但如果我们可以直接访问密钥（密钥可以基于时间或逻辑深度），那么我们可以立即遍历任何可能的情况，而无需启动整个过程再次使用新数据。
可以把它想象成一棵树，其中没有子节点的节点是最终结果，节点与其父节点或子节点之间的每个分支都是一个“状态”，每个分支都有不同的键控。因此，虽然只有 8 个叶子，或者该过程的最终结果，但可能存在许多“状态”，具体取决于逻辑在没有子节点之前沿着树向下走的深度。
也许用于模拟，但这需要大量内存。
对于一般程序，这将无法解决。停止问题证明不可能确定程序是否会停止。确定给定状态是否可能的问题可以归结为停止问题，因此也无法解决。
我认为这种方法对于任何事情都是完全难以处理的。
作为一个搜索问题，它太大了。如果我们假设每个状态可以导致 10 种结果（尽管我认为这个数字真的很低），那么为了向前看 20 步，我们现在必须跟踪 2000 亿种可能性。
请记住，循环中的每一步都算作一个分支点。因此，如果我们的代码如下所示：
for (int i=0; i < 100; i++)
some_function();
那么可能的状态数是（some_function内部的分支数）^ 100
虽然 Josh 是对的，由于它的模棱两可，您无法回答这个问题的最自由版本，但如果您对您的场景设置一些限制，您可以回答它。您的程序状态与业务实体的状态之间存在很大差异。
例如，假设您有一个由 DFA（状态机）定义的面向工作流的应用程序。然后，您实际上可以将该 DFA 中的给定点与某种 id 相关联。
所以是的，它是易于处理的，但并非没有限制。
这是在功能级别上完成的；这是一种称为memoization的技术。
研究克里普克结构和模态逻辑。这是建模程序中采用的一种方法。我忘记了使用这种方法的经典系统是什么。
瑞安，答案是肯定的。
与第一个答案相反，停止问题并不能证明任何事情。事实上，瑞恩，你的建议证明了错误的停机问题不适用于真正的数字计算机，我以前曾用这个例子作为证明。
在确定性数字系统（即在真实数字硬件上运行的程序）中，可能状态的数量是有限的，因此所有可能的状态都是可枚举的。
哈希所需的确切内存量为：
(2)*(program state size)*(number of initial states)
初始状态将是您的哈希键，最终状态将是哈希值，然后每个初始状态都有一个键/值对。
对于操作系统，“程序状态大小”为 2^（所有系统设备的总内存千兆位）。显然，如此大的通用程序需要不切实际的内存量来散列，并且无论如何都不会有用，因为系统是自引用/不可约复杂的（即下一个用户输入取决于先前的系统输出）。
解释：
这非常有用，因为如果您索引每个可能的初始状态并将其与终止状态相关联，您将有效地将任何程序的运行时间归零！任何为零，我的意思是非常快的 O(1) 运行时间——查找终止状态（如果它终止）所需的时间。
运行一个程序，从所有可能的状态开始，将提供一种显示循环的状态图。 因此解决了停止问题，因为在给定任何可能的初始状态时，只有三种（实际上是四种折叠为三种）可能性：
或 4. 最简单的程序将从初始状态开始，将进入所有可能的状态仅一次，然后别无选择，只能 (3) 停止或 (4) 重新进入先前遇到的状态并永远循环。
for (int i = 0; true; i++); //i 将达到最大值，回滚到零，此时它将重新进入初始状态
因此，基本上，您的索引可以这样描述：
换句话说，对于每个初始状态，程序要么达到终止状态，要么重新进入自初始状态以来已经遇到的状态并无限循环。
因此，对于在确定性数字硬件上运行的任何程序，绝对有可能（但通常不切实际）确定其所有状态以及它是否永远停止或循环。
除了强制任何程序的运行时间为 O(1) 操作之外，捕获状态的其他用途包括游戏控制台模拟器中的保存状态功能和计算机的休眠功能（尽管不是完美的状态恢复，因为必须使用一些系统内存对于恢复状态的代码和一些内存可能永远不会被存储（例如GPU内存））。
这证明了任何程序都可以用哈希表来表示。任何程序都可以用初始到最终状态转换图来表示。 所有程序都可以简化为一个具有大量内存占用的大功能！