fractals - Julia 集渲染中出现意外错误

Question

我正在玩 Mandelbrot 和 Julia 集，我遇到了有趣的问题。 Mandelbrot 集可以以 double 渲染，直到在任何地方缩放约 2^56。但是，Julia 集有时会更快地产生伪像，例如 2^20 左右的缩放(见下图)。



有趣的是，这仅发生在某些区域，但图像的其余部分还可以，您甚至可以继续放大。这通常发生在簇的中心和原点 [0,0] 附近。

这真的是由双重算术错误引起的吗？

可以在不需要使用任意精度算术的情况下避免这些工件吗？

为什么它只发生在某些地区？这些区域是不是有些特别？

坐标

我没有上图的坐标，但可以在此处找到另一个坐标(如下图):

中心 = [0, 0]

缩放 2^26

C = [-8.01030596311150589e-01, 1.56495138793530941e-01]

任意精度

以任意精度运行代码似乎有帮助，但只有一点点。 82 位的任意精度比 double 更好，但 232 位与 82 完全相同。也许我的实现有缺陷？唯一精度较低的数字是取自 Mandelbrot 集合的参数 C，它具有在设置的深度捕获它所需的精度 - 我认为这并不重要，因为添加额外的零来使精度高不会改变结果。计算结果的直接变量都是高精度的。

double :



任意精度 82 位:



任意精度 232 位:



代码

这是我代码的核心(省略了不必要的部分):

public void UberCompute(UberComplex origin, UberComplex size,
        UberComplex initialCoord, int maxIters, double[,] result,
        ref bool stop) {

    int wid = result.GetLength(1);
    int hei = result.GetLength(0);
    int area = wid * hei;

    int precision = Math.Max(origin.Precision,
        initialCoord == null ? 0 : initialCoord.Precision);
    UberComplex coord = new UberComplex(precision);
    UberComplex step = new UberComplex(precision);
    UberFloat.Div(step.Re, size.Re, wid);
    UberFloat.Div(step.Im, size.Im, hei);

    UberFloat imed1 = new UberFloat(precision);
    UberFloat imed2 = new UberFloat(precision);
    UberFloat imed3 = new UberFloat(precision);

    for (int y = 0; y < hei; ++y) {
        // double yt = (double)y / hei;
        // double im = origin.Im + yt * size.Im;
        UberFloat.Mul(imed1, step.Im, y);
        UberFloat.Add(coord.Im, imed1, origin.Im);

        if (stop) {
            break;
        }

        for (int x = 0; x < wid; ++x) {
            // double xt = (double)x / wid;
            // Complex coord = new Complex(origin.Re + xt * size.Re, im);
            UberFloat.Mul(imed1, step.Re, x);
            UberFloat.Add(coord.Re, imed1, origin.Re);

            result[y, x] = UberIterate(initialCoord ?? coord,
                coord, maxIters, smooth, imed1, imed2, imed3);
        }
    }
}

public double UberIterate(UberComplex coord, UberComplex initialCoord, int maxIters,
        UberFloat imed1, UberFloat imed2, UberFloat imed3) {

    Contract.Requires(imed1.Precision == initialCoord.Precision);
    Contract.Requires(imed2.Precision == initialCoord.Precision);
    Contract.Requires(imed3.Precision == initialCoord.Precision);

    int precision = coord.Precision;
    UberFloat re = new UberFloat(precision, initialCoord.Re);
    UberFloat im = new UberFloat(precision, initialCoord.Im);

    int i = 0;
    do {
        // re * re + im * im > maxRadiusSq
        UberFloat.Mul(imed1, re, re);
        UberFloat.Mul(imed2, im, im);
        UberFloat.Add(imed3, imed1, imed2);
        if (imed3 > MAX_RADIUS_SQ) {
            break;
        }

        // newRe = re * re - im * im + coord.Re;
        UberFloat.Sub(imed3, imed1, imed2);
        UberFloat.Add(imed1, imed3, coord.Re);

        // im = 2.0 * re * im + coord.Im;
        UberFloat.Mul(imed2, re, im);
        UberFloat.Mul(imed3, imed2, 2);
        UberFloat.Add(im, imed3, coord.Im);

        // re = newRe;
        UberFloat.Swap(re, imed1);
    } while (++i < maxIters);

    if (i == maxIters) {
        return Double.NaN;  // Did not diverged.
    }

    return i;
}

其他软件

我已经测试过 Ultra Fractal，它也有这个问题:

Answer 1

前段时间我开始渲染几个像 Julia 集这样的分形，现在我发现了同样的现象。
由于您的问题很老，我不确定您是否仍然对此感兴趣，但我会尽力解释。
您已经假设它与浮点表示的限制有关，这是正确的。
浮点表示意味着范围和精度之间的权衡，如 Wikipedia 中所述。 .
您可以看到，可表示的数字的数量级越大，它们之间的距离就越远。
(我不能详细介绍，因为我不是数学人。)
因此，可能有三个不同的数字 a、b 和 c 可以表示为浮点数
在哪里

a 和 b 的量级很小并且彼此非常接近并且

c 大得多，因此使用浮点算术计算 a + c 的结果与 b + c 相同。

这正是发生的情况，尤其是在围绕原点迭代此 Julia 集的函数时。
为了证明这一点，我从你的第一张图像中取了两个坐标 p 和 q (它似乎是围绕 x 轴镜像的)
并将它们用作算法的初始值:
p and q choosen from your first image

p := (-1.5615161e-8, -9.176949e-9)

q := (-1.3292692e-8, -1.0307186e-8)

c 来自您的示例 := (-8.01030596311150589e-01, 1.56495138793530941e-01)

在第一次迭代时，我得到了这个(使用 double ):
p² = (1.5961686010731998e-16, 2.86599072247578e-16)
p² + c = (-0.8010305963111505, 0.15649513879353122)
q² = (7.045757736826799e-17, 2.7402049776942403e-16)
q² + c = (-0.8010305963111505, 0.15649513879353122)
你有它。在第一次迭代时，数字变得相同。
请注意，像 10^(-8) 这样的平方数会导致更小的数字，例如 10^(-16)，这使得错误更加突出。
我还发现了其他离原点更远的初始值，并且在一些迭代后也使算法表现相同，并编写了一个小 Haskell 程序来进行计算:

import System.Environment
import Data.Complex
import Control.Monad
import Text.Read

main = do
    args <- getArgs
    case processArgs args of
        Just (c, z, r) -> do
            putStrLn $ "c = " ++ show c
            putStrLn $ "z = " ++ show z
            putStrLn $ "escape radius = " ++ show r
            printIteration `mapM_` juliaSequence c z r
        Nothing -> putStrLn "Invalid argument format"

processArgs :: [String] -> Maybe (Complex Double, Complex Double, Double)
processArgs args = do
    when (length args /= 5) Nothing
    [cRe, cIm, zRe, zIm, r] <- readMaybe `mapM` args
    return (cRe :+ cIm, zRe :+ zIm, r)

juliaSequence c z r = (takeWhile inEscapeRadius . tail . iterate julia) (-1, 0, 0, z) where
    julia (nMinus1, _, _, z) = (nMinus1 + 1, z, z2, z2 + c) where z2 = z * z
    inEscapeRadius (_, z, _, _) = magnitude z < r

printIteration (n, z, z2, z2PlusC) = do
    putStrLn $ "\nn :=      " ++ show n
    putStrLn $   "z =       " ++ show z
    putStrLn $   "z^2 =     " ++ show z2
    putStrLn $   "z^2 + c = " ++ show z2PlusC

这是这些点的输出在第 123 次迭代时的样子:

(1.2353312256782e-2, -1.4127067356406e-2)

(1.2353312257859e-2, -1.4127067356414e-2)

> runhaskell DebugJuliaSet.hs -8.01030596311150589e-01 1.56495138793530941e-01 1.2353312256782e-2 -1.4127067356406e-2 2
...
n :=      123
z =       (-0.23523642439355696) :+ (-0.1401978675009405)
z^2 =     3.568073330965438e-2 :+ 6.595929011704581e-2
z^2 + c = (-0.7653498630014962) :+ 0.22245442891057676
...

> runhaskell DebugJuliaSet.hs -8.01030596311150589e-01 1.56495138793530941e-01 1.2353312257859e-2 -1.4127067356414e-2 2
...
n :=      123
z =       (-0.23523642439355696) :+ (-0.14019786750094054)
z^2 =     3.5680733309654364e-2 :+ 6.595929011704584e-2
z^2 + c = (-0.7653498630014962) :+ 0.22245442891057676
...

一旦数字相等，算法就会采用完全相同的执行路径
并且数字在相同数量的迭代后通过逃逸半径。
这是这与 Mandelbrot 集的功能之间的关键区别。
在 Julia 集合中，像素坐标只影响算法的初始化，
而在 Mandelbrot 集合中，像素值会影响 C，它会在每次迭代中添加。
因此，相似的值更有可能采用不同的路径，因此通过逃逸半径的迭代次数也不同。
我能想到的解决这个问题的唯一方法是使用更高精度的数据类型
使用 C++ 渲染这个分形时，我尝试了 __float128和 long double在我的情况下，我猜有 80Bits。
程序变得更慢，但伪影似乎只在更深的变焦下才会出现。
Rendering with double in C++ - Center: (0, 0); Zoom: 17665391; Iterations: 2283
Rendering with long double in C++ - Center: (0, 0); Zoom: 17665391; Iterations: 2283
Rendering with long double in C++ - Center: (0, 0); Zoom: 879474690; Iterations: 2283
在您的情况下，这似乎效果不佳，您的包装器似乎有缺陷。
您如何准确地表示自定义数据类型中的值？
也许你也可以考虑使用 Decimal来自.NET:
我希望，现在对你来说事情更清楚了。