Julia集渲染中出现意外错误

时间:2014-09-23 04:14:04

标签: fractals double-precision arbitrary-precision mandelbrot

我正在玩Mandelbrot和Julia套装,我遇到了有趣的问题。 Mandelbrot集可以双精度渲染,直到在任何地方大约2 ^ 56的变焦。然而,朱莉娅集有时会产生很多伪影,比如缩放2 ^ 20左右(见下图)。

Julia set error

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

  1. 这真的是由双算术错误引起的吗?
  2. 可以在不需要使用任意精度算术的情况下避免这些伪影吗?
  3. 为什么只在某些地区发生?那些区域有点特别吗?
  4. COORDS

    我没有上面图片的坐标,但可以在这里找到另一张图片(如下图所示):

    • 中心= [0,0]
    • 放大2 ^ 26
    • C = [-8.01030596311150589e-01,1.56495138793530941e-01]

    任意精度

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

    双精度:

    Double precision

    任意精度82位:

    Arbitrary precision 82 bits

    任意精度232位:

    Arbitrary precision 232 bits

    代码

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

    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,它也有这个问题:

    Ultra Fractal

1 个答案:

答案 0 :(得分:2)

前一段时间,我开始渲染像朱莉娅集合这样的分形,现在我发现了相同的现象。 由于您的问题已经很久了,所以我不确定这是否对您仍然很有趣,但是我会尽力解释。

您已经假定这与浮点表示法的局限性有关,这是正确的。 如Wikipedia中所述,浮点表示表示在范围和精度之间进行权衡。 您会看到,可表示数字的大小越大,它们彼此之间的距离就越远。 (因为我不是数学家,所以我无法详细介绍。)

因此,可以使用三个不同的数字a,b和c表示为float 在哪里

  • 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)

就在第一次迭代中,我得到了这个(使用双精度):

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 ++渲染此分形时,我尝试了__float128long 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

在您的情况下,这种方法似乎效果不佳,包装程序似乎有缺陷。 您如何精确地表示自定义数据类型中的值? 另外,也许您可​​以考虑使用.NET中的Decimal

我希望现在对您来说情况变得更清楚了。