问题标签 [precompute]

我的 Python 类有一些变量需要在第一次调用时进行计算。后续调用应该只返回预先计算的值。

除非用户确实需要它们，否则我不想浪费时间做这项工作。那么有没有一种干净的 Pythonic 方式来实现这个用例呢？

我最初的想法是第一次使用 property() 调用一个函数，然后覆盖变量：

谢谢

我经常处理聚合实体或父实体，这些实体具有从其组成成员或子成员派生的属性。例如：

• 一个对象的byte_countand是从它的两个组成对象的相同属性中计算出来的，而这两个组成对象又是从它们的组成对象中计算出来的。packet_countTcpConnectionTcpStreamTcpPacket

• 一个Invoices对象可能有一个total基本上是其组成部分InvoiceLineItems价格的 SUM() 的值，其中包含一些运费、折扣和税收逻辑。

在处理数百万个数据包或数百万个发票行项目（我希望！）时，这些派生属性的按需计算——无论是在视图中，还是在更常见的表示逻辑中，如报告或 Web 界面中——通常速度慢得令人无法接受。

在性能问题迫使您动手之前，您如何决定是否将派生属性“提升”到预计算字段？

我有一个很大的字符串列表（超过 200,000 个），我想将它们与给定的字符串进行比较。给定的字符串是由用户插入的，因此可能略有不正确。

我希望做的是在将每个字符串添加到列表时创建某种预先计算的哈希值。该哈希将包含诸如字符串长度、所有字符的添加等信息。

我的问题是，这样的东西已经存在了吗？肯定会有一些东西可以让我避免在列表中的每个字符串上运行Levenshtein 距离吗？

或者也许我还没有想到第三种选择？

我正在尝试使此触发器起作用：

这个想法是仅在 tbl_art.e 更改时计算 tbl_art.f 的值。
NEW.f 应该是 NEW.e * [查询返回的值]

请问有什么帮助吗？

假设我们有一个这样的程序：

我希望将其编译为可执行文件仅打印 50000005000000，而无需花费太多时间和精力。

基本上，任何肯定会被计算的表达式（也许严格性分析在这里会有所帮助）都可以在编译期间预先计算（即我们使用引用透明性来表示计算值时并不重要）。

简而言之：“必须计算”+参考透明度=可以预先计算

这就像运行程序，直到我们遇到依赖于输入的东西（即程序的核心，所有输入通用的，将被预先计算）

目前是否有实现这一目标的现有机制（用 Haskell 或任何其他语言）？[请不要指向 C++ 中的模板之类的东西，因为它首先没有引用透明性。]

如果不是，这个问题有多难？[伴随的技术（和理论）问题是什么？]

我正在尝试按行预先计算用户定义的函数。这个想法是我在其中一个字段中将 JSON 对象作为文本对象，并且我想从中解析出一些其他“字段”，这些字段可以像任何其他真实字段一样在查询中返回。但是，解析 JSON 的开销很大。有没有办法以加速查询的方式预先计算这个解析函数？

请不要争辩说首先不应该有 JSON 作为数据库上的文本；我知道利弊。

我为数据库中的所有点预先计算了距离矩阵。我正在尝试使用以下命令调用 ELKI gui：

但我不断收到以下错误消息：

参数格式错误！参数“dbscan.epsilon”需要距离值，但距离没有设置！

我无法弄清楚我在这里做错了什么......

是否有一个好的模式可以让我使用模板从给定的元素类型、所需的长度和自定义函数生成预先计算的数组f(int index)？

考虑这个 C 风格的实现。

用模板做同样事情的最干净的方法是什么？它必须允许我指定数组中元素的数量并允许我提供某种用户函数（索引作为参数）。函子、std::function、 lambda、 函数指针等可能都是定义元素生成器的可接受方式。

我可能希望将模板显式实例化一次到 obj/lib 中，以便表本身只定义一次，作为可链接符号，而不是重新编译到包含标头的每个 .cpp 文件中。

我在 WebGL 中使用 cubeTextures 预烘焙 nVidia 的 PCSS 工作了 2 个月。我已经成功地实时实现了野兽。预烘焙它最终也可以工作，但有一些明显的伪影。

简而言之，在下面我突出显示我拥有的主要工件并解释为什么我得到它，在一般情况下，如果每个人都尝试预烘焙软阴影，应该会遇到这种情况。总结这个线程，围绕这个问题的每一个建议都可以帮助我：

我们如何处理预烘焙的软阴影伪影？

让我们通过讨论软阴影而不是专注于 PCSS 来简化情况。这意味着我们正在使用一个 shadowMap，其中每个 texel 的可见性值范围为 0 到 1（而硬阴影生成的 shadowMaps 只有 2 个可能的值：0 或 1）。

由于我们不是实时的，我们必须固定一个视角，而不是在每一帧使用相机视角。我的软阴影是从光的角度计算的。为了构建它们，我：

• 计算带有所有阻塞器（遮挡器）的基本 shadowMap
• 在仅包含接收器的第二遍中，我使用 shadowMap 计算软阴影并存储每个像素的可见性

这给了我一个预先计算好的 shadowMap，我可以实时采样。

预烘焙软阴影的第一个限制是阻挡器不能成为接收器的一部分。想象一个充满遮挡物的房间，那么唯一的接收器肯定是房间。否则，您将失去房间网格上的一些阴影。原因是我们被困在了光的角度，所以如果我们也把它当作接收器，我们就看不到阻挡器背后的东西。

这种限制导致得到一个对房间具有良好可见性值的 shadowMap，但对于阻挡物上的阴影显然不是很好。我不介意在障碍物上获得正确的可见性值，我希望能够使用房间的阴影作为障碍物上阴影的近似值。但在实践中，您会在遮挡物上获得硬阴影，因为在遮挡物后面，房间阴影的可见性值是全黑的。

这是一个图表来说明为什么会发生这种情况。

在最上面的情况下，我只把房间当作接收器。在底部情况下，我也使用拦截器作为接收器。您可以很容易地看到在这两种情况下都出现了问题。因为对于 shadowMap 的相同纹素，我们需要两个不同的可见性值：房间上的点是全黑的，而遮挡物上的点是半影。

我有很多想法来处理这个工件：

1. 向着色器发送每个网格的 meshId 并评估此 id 以了解我们是否正在遮蔽阻挡器。
2. 分别为每个拦截器制作一个 PCSS 通道，并在最后混合所有 shadowMaps。
3. 分别为每个接收器制作 PCSS 通行证（考虑到拦截器）。
4. 预先计算一半的计算并实时进行另一半。
5. 从多个角度预计算 shadowMap，而不是从光的角度。

我在 1 和 2 上失败了。想法 3 似乎与想法 2 相同。4 很愚蠢，它不再是预计算了。而且我担心我将无法使想法 5 通用。

关于这个主题的文档真的很少。而且我发现的大多数文档都适用于理想场景，没有阻挡器遮蔽另一个阻挡器，就好像这不是通常的情况一样。所以也许这里有人已经面临这个问题或者对这个主题感兴趣？希望它也能帮助我之后的其他人。

不过，感谢您考虑这个问题。

我使用 Scikit-Learn 的最近邻/半径分类和预先计算的指标。这意味着，我将成对距离的 n_samples_train x n_samples_train 矩阵传递给分类器的拟合方法。

现在我想知道为什么必须这样做。使用 knn 学习只是意味着“存储样本”，但是距离的计算应该只在稍后进行，在泛化过程中（在那个步骤中，我当然会计算我的训练样本和我的测试样本之间的距离矩阵，所以大小为 n_samples_train x n_samples_test 的矩阵）。

例如，在 SVM 的情况下，我将预先计算的矩阵（Gramian，相似矩阵）传递给 smv.SVC 对象的 fit 方法。然后进行优化，找到支持向量等等。在那里，该矩阵在训练期间是绝对必要的。

但是我看不出为什么需要一个预先计算的矩阵来拟合邻居/半径分类。

有人可以给我一个相关的提示吗？

我很想用 scikit learn 跳过计算 knn 的训练矩阵。

最好的问候，谢谢。:-)