什么是在数据库中存储Mandelbrot值的最佳方法？

Question

我正在尝试渲染一个Mandelbrot集,我很快就意识到不必重新计算每次渲染的最大迭代次数......另一方面,它需要大量的数据来跟踪的.在我看来(基于我对RDMSes的有限经验),关系数据库可能不是可行的方法,因为我不希望随着数据集变大而影响性能.它几乎看起来像哈希表的完美情况,但我以前从未使用过,似乎无法解决如何使用或管理现有的一种Web服务器语言(Python/PHP /无论如何).

更明确一点:要存储的重要值是:

• 复杂平面上数字的原始实部
• 复平面上数字的原始虚部
• 数量最多的迭代
• 命中最大迭代之前的完成迭代次数 n或直到该点运行到无穷大
• n次迭代后复平面上数字的最后一个实部
• n次迭代后复平面上数字的最后虚部

在任何给定的时间,给定原始实部,原始虚部和最大迭代次数,我希望能够得到具有最终实部和虚部的结果集.

所以你怎么看？哈希表是否可行？这个问题对于凡人数据结构来说是否过于复杂？

任何帮助都将非常感激.提前致谢!

编辑

我会根据julienaubert的要求对这个问题进行一些阐述.

我的目标是允许用户在没有计算延迟的情况下放大Mandelbrot集(即使它是通过预定义的缩放).我还希望能够在浏览器中执行此操作,该浏览器不断要求服务器提供新的数据数组,以便在复杂的平面上查看新的x和y坐标以及高度和宽度.但是,由于计算像素颜色值可以更快地完成(给定max_iter,real_final和imag_final),并且因为允许用户调整颜色设置会很好,所以我只会发送浏览器在我的帖子中枚举的变量,让用户的浏览器计算颜色.

看看这个:

http://jsfiddle.net/xfF3f/

如果查看drawMandelbrot()函数,可以看到点循环将重要值存储在名为dataset的变量中.然后在drawMandelbrotFromData()函数中使用此变量,在该函数中,它执行计算每个像素颜色所需的剩余计算.

如果单击"cleardabrot",它将用白色矩形替换画布.如果单击"refilldabrot",它将再次运行drawMandelbrotFromData()函数...这样做是为了向您显示实际渲染集合的速度,只要它不必执行痛苦的迭代计算.

因此,这里的最终目标是能够将这些值计算为任意精度,因此用户可以缩放到该集合的任何级别,让服务器弄清楚是否有这些精确点的任何数据(或者,最好是点NEAR那些确切的要点......虽然我不确定如何在不执行某种范围查询的情况下完成这项工作,然后逐个像素地回吐信息.例如...

• 用户正在使用300x300画布.
• 他放大到一个地步,左上角是x = .000001和y = .0000231.
• 他在这个框架中选择的宽度和高度是w = .00045和h = .00045

他会将这些数字发送到服务器并依次接收一个包含300*300索引的数组(一个代表每个点),每个索引包含确定画布上每个像素颜色的必要信息.我的问题是......存储预先计算的Mandelbrot数据的最佳方法是什么,这样用户可以输入任意的x,y,w和h值,并快速拉回复平面上的点的值.范围.

Answer 1

在任何给定时间，给定原始实部、原始虚部和最大迭代次数，我希望能够获得包含最终实部和虚部的结果集。

从你的问题中不清楚为什么你需要这个？为什么同一点需要重新计算？

如果您正在尝试不同的 max_iterations 设置，您可以将每个像素级别的实际迭代保存在二进制文件、文本文件或图像或您认为方便加载/存储的任何内容（例如关系数据库）中。

如果您正在进行实时渲染并且正在使用一些需要重新计算递归方程的处理（在相同的原始点和相同的最大迭代次数），那么我想您可以通过查看来加快速度-上桌。

显然，您的查找表必须比计算速度更快。您需要一个查找表，其中以下操作总共花费的时间少于再次进行计算的时间。

• 计算索引（给定 origo_real、origo_imag、max_iter）
• 加载缓存的计算（final_real、final_imag、actual_iter）
• 一个初始商店

根据您在相同点重新计算/重新访问的方式，您可以以这样的方式划分问题：索引很可能位于查找表中并且查找表足够小存储在 L1 或 L2 缓存中。

这些是一些想法..但你应该澄清你真正的问题是什么。

如果您只需要大量此类数据进行进一步分析，并且不需要实时性，那么...澄清您真正的问题是什么:)

更新的答案

它看起来类似于使用地图服务（放大/缩小、四处移动），也就是说，您本质上是为给定区域提供图像并进行缩放。

但是在这种情况下，由于可能会查询任何缩放级别，因此您为一个用户缓存的任何内容都可能不会被下一个用户重复使用。我不确定为什么这样做有意义，而不是编写一个用户可以实时缩放的客户端软件（已经完成）。

任何状况之下。如果您的主要问题是带宽，但您有足够的计算能力，那么您可以将计算出的补丁的图像存储在高度压缩的文件中，质量稍低并缓存这些图像。然后，您可能需要将这些补丁缝合在一起，以提供用户想要的确切区域。技巧是查询给定缩放和区域的最小补丁集。

我担心大多数查询会要求不存在的补丁（因为任何缩放级别都是可能的）。也许一些关于谷歌地图/地理信息系统如何工作的信息可以给你一些想法。如果您的主要问题是 CPU，那么也许您可以采取不同的做法，让用户在 Applet 中进行计算（并可能发回结果）

如果您这样做是为了学习如何通过客户端服务器进行缓存/计算，您可能需要考虑一个不同的挑战，因为这个问题可以通过任何像样的计算机在客户端解决。