Skip to content

Precision #15

@Sekqies

Description

@Sekqies

Right now, we are representing complex numbers as vec2. This is great for performance but bad for precision, since we are limited to floating point precision for both imaginary and real components. One may think that the logical solution is to just use double precision (after all, modern GPUs support types such as dvec2), but this causes HUGE performance issues, because GPUs are not optimized for double.

Samuel Li implemented in his complex function plotter complex numbers as vec3 in log-cartesian coordinates. In his representation, (a,b,c) has a normalization constraint of a^2 + b^2 = 1, and c would represent a magnitude. You get a complex number $z$ as $z = (a+bi) \cdot e^{c}$. So, if you wished to represent 2^2000 normally, you'd get a floating point explosion, but with his method, this is simply (1,0,2000*ln(2)). Great stuff! If you hadn't known this, his plotter is my greatest inspiration for this project.

Henry Thashler has an article in which he implements simulated double precision, meaning our complex numbers would be stored as a vec4, which would be essentially (x_lo,x_hi,y_lo,y_hi). This, of course, comes with a great headache of implementing everything manually and a noticeable performance hit.

There is also another implementation similar to Samuel's that represents numbers as simply $z = r \cdot e^{i\cdot \theta}$, and you store an auxiliary variable $k$, a "winding" number, to know how many times the angle $\theta$ has wrapped around itself.

I'll have to do more research to see if I find any other alternatives, or if I come up with something myself, because ripping off samuel's precision trick feels cheap to me...

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions