cceckman / fractal-farlands Goto Github PK

We're using Mul<Complex> to square it in the Mandelbrot computation, but squaring complex numbers needs fewer ops:

(a+bi)(c+di) = (ac-bd) + (ad+b*c)i

(a+bi)^2 = (a^2-b^2) + 2abi

Need to be able to construct a '2' for the generic type N in Complex

Drafted on the writeup branch, along with a markdown -> PDF script that runs via LaTeX. Fun thing: it's set up to fetch images via URL from localhost:3000 when it renders!

I have essentially no experience with LaTeX, but I think we might be able to convince Pandoc to stop at .md -> .tex, using some template for .tex, and then edit from there?

Implement MandelbrotNumber and plumb through.

Can convert from BigRational by splitting into integer and fractional parts, and keeping the most significant fractional pieces.

The way the renderer is set up today, we provide an exact window as BigRational coordinates (BigInt numerator and denominator). We convert the edges of the rendering window to the target format, divvy the window up into pixels, and run the fractal for each pixel.

The constraint on the numeric formats - at least for Mandelbrot - is that they implement

fn from_bigrational(value: &BigRational) -> Option<Self>;

so that they can get an as-correct-as-possible representation of the window.

from_bigrational is already implemented for f32 and f64 (by the num crate maintainers). It's pretty easy to do for fixed-point formats (#1) : use BigRational::trunc and BigRational::fract to get BigInts, and truncate them into the fixed-point fields.

I'm not sure how to go from BigRational to posit (#3); it's a trickier rounding problem.

Do we want/need to use BigRational as the intermediate format? Is there something more generally supported, like f64, that's still "good enough" as a superset of other formats of interest?

What are neat locations / settings?

There are a few ways to smoothly color the Mandelbrot set, e.g. https://rubenvannieuwpoort.nl/posts/smooth-iteration-count-for-the-mandelbrot-set https://linas.org/art-gallery/escape/escape.html Smooth coloring might be nice.

Other things we could do:
Automatic dwell limits: https://mrob.com/pub/muency/automaticdwelllimit.html So we don't need to put the iteration count

This article has some cool variations, including adding the number of iterations or escape angle to the coloring: https://mrob.com/pub/muency/color.html

Implement MandelbrotNumber for posits; soft_posit crate may be useful.

Conversion from BigRational is ??

CPU-based rendering is CPU-bound; BigRational has pegged a CPU on my computer for a while.

Our maximum parallelism is "every pixel" but that seems inefficient unless running on a GPU; (512x512) is a fair number of threads.

But we have a sliding scale in between, by tiling the image.

• Splitting rendering into tiles doesn't change any of the data types, i.e. MandelbrotEval. We could even make TilingEval meeting the same interface.
• If we're in an async context, we could spawn even more tiles.
• ...in a dedicated pool (CPU pool as distinct from the request pool) to avoid blocking the request thread, allow cancellation, etc.

For manual exploration.

Want to have, in rough order:

• Basic rendering, from input coordinates
• Toggleable display (e.g. "skip BigRational, it's too slow", then turn it on later)
• Click and drag to zoom on area
• "resquare"- match x/y zoom
• "back button" to go to the previous view

Some non-technical considerations:

• Cancelable rendering: if we zoom or back out, free up the CPUs again. Requires relatively deep plumbing.

I'm tempted to just use the browser as the UI. Automatic "back" support (using GET queries), and rendering with cancelable futures gets us thread pools etc. for parallelism.

This feels like a bug.

Zooming in on -1.5, 0i,

f64

MaskedFloat<3,50>