dongyx

multiprocessing 模块有一个叫做 start_method 的全局模块属性。如果设置为 spawn ，那么启动的子进程会重置为一个干净的 Python 解释器并重新定位到要执行的函数，相当于于执行 fork+execv 系统调用然后执行你的函数。如果设置为 fork ，子进程会写时拷贝父进程的虚拟地址空间，类似于执行 fork 系统调用之后直接执行函数。

当 start_method 被设置为 spawn 的时候，Process 对象的 args 参数是通过 pickle 模块序列化之后跨进程传递给子进程的。而 pickle 在序列化类和函数的时候，仅仅是保存他们的完整名字引用。所以你可以认为你的 Example 类被序列化为一个类似于 b'__main__.Example'的字节序列。子进程通过这个名字定为 Example 类，而子进程是一个干净的解释器，所以 Example 类也是干净的。

在 UNIX 上，Python 默认使用 fork 模式，而在 Windows 上默认使用（也只支持） spawn 模式。但是有一点要特别注意，尽管 macOS 是一个 UNIX ，但是从 Python 3.8 开始，也以 spawn 作为默认的 start_method （但保持对 for 的支持）。

你可以选择在程序引入 multiprocess 模块后，通过执行`multiprocessing.set_start_method('fork')`来解决你的问题。

@efaun 哪里那么容易圈到钱，如果有得赚，何必不继续赚下去呢。

@baoshuo 领域不一样，这种写法是竞赛环境下的好写法。对于搞竞赛的队友来说，因为常用所以并不坑人。毕竟“坑人”指的是违反直觉的写法。但是这种环境下大家都写多了看到这种代码是可以马上建立直觉的心理模型的。

哈哈，我也相同癖好，不过比你还要广泛一点，我喜欢所有的老桌面系统的图片，风格不比 win 98 现代的我都爱。

@yazinnnn

假设你讨论的是实际机器上运行的纯函数，那肯定是可以判定的，大不了你枚举所有可能的参数。实际机器上的函数的参数总是可以被枚举完的，比如你说的两个 32 位 int 型参数，总共 2^64 种情况给你枚举。但是除非的你的问题涉及到的参数类型非常特殊，不然性能上肯定是不能接受的。

如果在你的问题中，函数的参数形式是比较一般的，你可以从函数体的实现限制去考虑。比如，在你的实际工程中，你要判定的函数是不是都是数学上简单的初等函数呢？加减乘除指数三角函数的有限组合与复合？是的话，你就可以用表达式树给你的函数建模。在一些语言中，你可以直接把这些基本运算覆盖了，让这些运算返回一颗表达式树，然后你的问题就变成一个更传统的算法问题：我怎么判定两棵树同构？这就好做多了。

如果不是简单的初等函数，比如可能有判断，循环。那就要再把模型的计算能力上升一下，比如你发现的这些函数虽然有循环和判断，但是他们所用的局部变量的个数不随输入而改变（不会根据传入的整数参数来决定要在函数里开多大的数组），那你就可以尝试用有限自动机去描述这些函数。每个自动机可以规约到一个最小自动机，然后你就又转化为一个传统算法问题，判断两个图是不是同构的，这个问题虽然没有高效算法，但是问题规模小，你的代码转换成自动机之后的节点数，比你的参数的可能情况要小太多，所以总体上还是可以解决的。不过在实现上，这个就比初等函数的情况要复杂了，你很难简单地把一个函数转化为自动机，要不然你写一个（或者找一个开源的）解释器，要不然你就必须提供一套基础函数 /类库，这套工具要替代语言里的基本运算和循环 /判断结构，让那些函数的作者用你这套工具重写他们的函数以便你获取函数的自动机语义。

如果自动机还是不能解决你的问题，那就需要更抽象的模型，比如下推自动机，我没有研究过，并不知道判断两个下推自动机同构的问题是否是可能的。

但是我的整个思路是这样的，因为从理论上说，判断任意函数等价不可能，工程上枚举所有输入又不现实。那就只能从需求出发，和合作者讨论清楚这个问题的边界，你要让我实现 [判断函数等价] 的功能，你必须给函数做限制，你说的函数是什么函数。然后做折衷，比如我们要不要只支持初等函数？这样成本最低，函数实现者什么额外工作都不用做。不行的话，你们的函数能不能都写成有限状态的？还是不能，那就讨论参数的形式能不能限定，限定到枚举量可以接受的程度。

非纯函数的问题本质上没有区别，让大家把外部环境改写为参数传进去。

如 @sillydaddy 所说，如果是任意函数，是不可能的。

但是，作为一个实用主义者，你可以给出更细范围的函数。虽然在图灵机范围内不可判定，但是如果限制到有限自动机，我看是可以的。把两个自动机都 minimize，然后判断是否同构。 幸运地是，现实中的很多函数用有限自动机就能表达。

有意思的问题。

我目前的思路是动态规划，计算顺序是一条对角线一条对角线地算，不断地填充左上三角。

算第 n 条对角线的时候，其实算一个一维的二阶递推式，需要 O(n)的时间，那么要算 f(n, n)需要 O(n^2)，感觉算 f(10000, 100000)有点吃力。我想看看能不能优化一下算一条对角线的做法，可惜系数不是常数，不然就可以矩阵快速幂了。

愿闻楼主高见。