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

Question

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

database-designdata-structureshashtablefractals

6

我目前正在尝试渲染曼德博集合，很快意识到不必为每个渲染重新计算最大迭代次数会很有用...另一方面，跟踪这么多数据是很困难的。根据我对关系型数据库的有限了解，它可能不是明智的选择，因为数据集越大，性能就会受到影响。似乎哈希表是完美的选择，但我从未使用过，并且无法弄清楚如何在现有的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（）函数...这是为了向您展示它实际上可以多快地呈现集合，只要它不必执行痛苦的迭代计算。

因此，这里的最终目标是能够以任意精度计算这些值，以便用户可以缩放到集合的任何级别，让服务器确定是否有这些确切点的数据（或者更好的是，接近这些确切点的点...尽管我不确定如何在不执行某些范围查询的情况下完成此操作），然后逐像素返回信息。例如...

用户使用300x300画布。
他缩放到一个点，其中左上角为x = .000001和y = .0000231。
在此框架中，他选择的宽度和高度分别为w = .00045和h = .00045

他将这些数字发送到服务器，并依次接收一个包含300 * 300索引（每个表示一个点）的数组，每个索引包含确定画布上每个像素的颜色所需的信息。我的问题是...最佳的存储预计算Mandelbrot数据的方法是什么，以便用户可以输入任意的x、y、w和h值，并快速地检索该范围内复平面上各点的值。

- treeface

深入探讨“在那些确切点附近的点...尽管我不确定如何在不执行某种范围查询的情况下完成这项工作”，您可以实现一个R树来索引给定坐标的计算结果。然后，您可以使用像素大小的给定边界框搜索结果。https://en.wikipedia.org/wiki/R-tree - Falk

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user348466 · Accepted Answer

在任何时候，给定原始实部、原始虚部和最大迭代次数，我希望能够获得一个结果集，其中包含最终的实部和虚部。从你的问题中不清楚你为什么需要这个？你为什么需要在同一点重新计算？如果你正在尝试不同的max_iterations设置，你可以在每个像素级别上保存实际迭代所需的二进制文件、文本文件或图像，或者任何你找到方便的东西，比如关系数据库。如果你正在进行实时渲染，并且你正在使用一些处理需要重新计算递归方程（在相同的原始点和相同的最大迭代次数下），那么我想你可以通过查找表来加速这个过程。显然，你的查找表必须比进行计算更快。你需要一个查找表，使得下面的操作总共要比再次进行计算少：计算索引（给定 origo_real、origo_imag、max_iter）、加载缓存的计算（final_real、final_imag、actual_iter）和一个初始存储。根据你将如何重新计算/重新访问相同的点，你可以将你的问题分解成高度可能索引在查找表中并且查找表足够小以存储在 L1 或 L2 缓存中的方式。这些都是一些想法...但你应该澄清你真正的问题。如果你只需要大量的这些数据进行进一步分析，而实时性不是要求，那么...澄清你真正的问题吧 :) 在这种情况下，似乎类似于使用地图服务（缩放、移动），也就是说，你本质上正在为给定区域和缩放级别提供图像。然而，在这种情况下，由于可能查询任何缩放级别，无论你为一个用户缓存什么，都可能不能被下一个用户重复使用。我不确定为什么用这种方式而不是编写客户端软件，在其中用户可以实时缩放（这已经完成了）。在任何情况下，如果你的主要问题是带宽，但你有足够的计算能力，那么你可以将一个计算出的补丁图像保存在高度压缩的文件中，质量稍低，并缓存这些图像。然后，你可能需要将这些补丁拼接在一起，以提供用户想要的确切区域...诀窍在于根据缩放和区域查询最小的补丁集。我担心大多数查询会要求不存在的补丁（因为任何缩放级别都是可能的）。也许一些关于如何工作的信息，如 Google Maps/GIS 系统，可以给你一些想法。如果你的主要问题是 CPU，那么也许你可以用 Applet 让用户在其中进行计算（可能会发送回结果）。

如果你想学习如何在客户端-服务器上缓存/计算，那么你可能需要考虑一个不同的挑战，因为这个问题可以由任何好的电脑在客户端解决。