Precision tests

[ClintTorres]

Lots of cruft and broken bits left around.

Still also pretty sure the gradation when using flint is some kind of bug, but I haven't found it yet, if it is.

[ClintTorres]

Introduces a DiveTimeline as the basis for dive calculations.
One useful example of setting up a timeline is in MediaView.construct_simple_timeline().
I suspect there's still a lot of one-off errors when it comes to how keyframes are handled.
I didn't spend a ton of time on that though, because we might need more precision of placement (rather than at an integer frame) too.

This version keeps the existing next_epoch()/calculate_epoch_data() mechanism, but the last bits that use it will probably be converted to the timeline-based frame render using render_frame_number() and an instantiated timeline.

This should run fine even if flint isn't installed.
Moved as much of the math precision alternates into DiveMathSupport class (and DiveMathSupportFlint subclass) to localize numeric types and calculations with different precision libraries.
This means different precision math types can be instantiated after parameters are read, instead of globally in advance.
This means the command-line parameters are read in as strings (without type casts), and then math subtypes do their own castings and instantiations.

Took out "mpmath" calcluations because the author warned us to use his ARB (and/or flint-wrapped) implementation instead, which is just better and faster.
This was also a little too big of a hammer, because it seemed to swap out all math operations for much slower versions?

Took out "Decimal" calculations, partly because there's no pre-built complex number representation.
Sure, we could make one, but then we'd have to also implement operations, and it just doesn't look worth it for something that only performs marginally better than mpmath.

I'm. Uh.... Sorry about mixing camel case and underscores as a convention.
Partly, I didn't bother converting from my native camel case because I'm not sure how much of this code should actually survive.
I should probably be forced to fix that sometime.

[ClintTorres]

Split out the MathSupport classes, and separately the DiveMesh classes, into their own files.

[ClintTorres]

There's now 2 results cache paths - a shared one for uniform meshes (stored by metadata hash), and a project-only one for non-uniform meshes (stored by frame number).

Cache is currently BROKEN for flint though.

I've tried to pull the last of the 'epoch' based calculations out, switching to 'timeline' based descriptions.

Whenever we calculate or cache results now, all 4 of raw_values, raw_histogram, smooth_values, and smooth_histogram are calculated and stored as a single results entry.
Obviously, this goes against the principle of not making one thing do two things, and is more work than always strictly necessary, but it seems like a useful convenience for now, especially since it doesn't really make anything more complicated.

Command line changed so 'julia-walk' uses the 'center' param, not its own julia-center.
Don't think julia set snapshots will work yet, because I'm not sure how to exactly specify what you want.

[ClintTorres]

Looking at frame generation

Main branch process:
calc curr frame info
-(depends on algo.calc_pixel())
(pre hook)set up hues in palette
calls draw_image_PIL

• relies on palette instance for color lookup

Branch version:
calc curr frame info
-(depends on timeline, which chooses an implementation algorithm)
build hues histogram
calls draw_image_PIL

• relies on hues param AND palette instance

So, to merge these approaches:
calc curr frame info (including hists)
-(rely on the timeline's algo instance)
palette gets its histogram set (doesn't use Palette's raw_calc_from_algo() since it's already calculated)
(pre hook) set up hues in palette
call draw_image_PIL

• relies on palette instance for color lookup

Looking at julia/mandelbrot implementation

MathSupport is a cross-cutting issue for the algorithm hierarchy.
Keeping math operations in close proximity to their parameters is tough, because the MathSupport needs to be implemented across the board for each calculation type.
I think this means grouping core functions by MathSupport type is cleaner than forcing them to live in the 'algo' implementation.

So, the algo is the structural organization, intermediates chaperoning, and hooks organization, while the MathSupport is the crunching.

Looking at epochs/timelines

An epoch is an evolution frame-to-frame across a trajectory.
This evolution is a step-by-step change of the base mesh inputs to fractal calculations.
But, an arbitrary frame of a fractal doesn't depend on previous frame data, since a frame's base mesh can be jumped to directly through an exponential.
So, we can calculate any arbitrary frame's properties in absence of previous frames.

A timeline is an endpoint definition of an evolution across a trajectory.
The timeline constructs a mesh for an arbitrary frame based on its timeline declarations, without depending on evolution over time.

Overall, this means we don't have 'animation' tracked through a context, but instead just frame numbers which can be arbitrarily calculated across the timeline.

Looking at performance and arbitrary precision

Vectorizing a numpy function (i.e. invoking functions across an entire matrix) greatly speeds up overall runtime.
So the calculation funcions are going to be best if we don't invoke them inside for loops, but instead make sure they're vectorizable and apply them to all pixels at once.

Writing our own entire-image-at-once calculation core in C (using an arbitrary precision library) might eventually move the needle more.

I think this means the primary algorithm invocation shouldn't be pixel based, but instead whole-mesh based.

We were warned away from using python mpmath by its creator, in favor of flint.
Flint is quite a bit faster than mpmath, perhaps because it doesn't hijack all math operations, but I'm not sure exactly.
Attempting a python Decimal implementation was much slower than either mpmath or flint.
An attempt at directly using the gmp library (instead of flint as an intermediary) showed that a gmp implementation is also much slower than flint.