#complex plane

Newton-Raphson Method of Sine in Complex Plane ⋈

Infinite Self-Similar Fractal, Convergent Sine Iterative

ive been thinking on and off about riemann spheres for a while now, a couple weeks really, and so far i think there's some utility to them as a building block of a type system of some kind for a joke/toy computer language

background: riemann spheres are a neat tool in complex analysis where we imagine a sphere whose equator intersects the complex plane, and every number on the complex plane is representable by a point on the sphere such that a line is projected from the north pole and through that point onto the complex plane. naturally, this means that the north pole is P(∞) and the south pole is P(0). see below how that would look like with other unit points of the complex numbers

a neat thing the riemann sphere allows us is to define meaningful division by zero so now z/0 = ∞ clean and simple! and also its inverse, z/∞ = 0 is well behaved as well. this simplifies doing complex analysis but stereographic projection is an absolute bitch to work with turns out, and doing arithmetic on points on the sphere is a mess because it's not a linear mapping (it's continuous though so that's fine)

if we're dealing with ONLY real numbers in relation to a circular slice of the riemann sphere, it already starts looking like a mess; for any number n∈R its projective cognate on the circle is located at (2n/n²+1, n²-1/n²+1). on the real riemann sphere though? zoo wee mamma

an arbitrary z∈C, represented as a point (x,y) on the complex plane, has to walk through a rather ugly mapping (related to the previous one) to find its point on the sphere; more accurately, given the coordinates (x,y) of the point on the plane, the point on the sphere is located at (2x/1+x²+y², 2y/1+x²+y², -1+x²+y²/1+x²+y²), which is godawful in spherical-to-polar coordinate terms, this is much simpler; for a polar pair (r,θ) the point on the unit sphere representing it is (φ,ξ) = (2*arctg 1/r, θ); and conversely projecting from the riemann sphere is also dead simple, given the zenith-azimuth pair (φ,ξ), (r,θ) = (ctg φ/2, ξ). of course, translating from polar to real coordinates is ALSO dead simple; x = r * cos θ, y = r * sin θ. if a computer system were to store complex numbers (or any coordinate on a 2d plane really), it makes sense to store them in terms of spherical coordinates of a riemann sphere, since this makes infinity well-behaved as a unit (zenith = 0, azimuth = literally who gives a fuck) and is surprisingly efficient. knowing that the zenith is ∈[0,π] and azimuth ∈[0, 2π] can allow for some formidably dumb optimisations that can save on space and ensure granularity. compared to storing them as 2d cartesian or polar coordinates, this provides the benefit of having neither number be larger than like 6.3, so an underlying/backing type that can offer great precision in this small range would be more efficient numerically than, say, floating points which have insane baggage and gaps

Consider ℝ², the real coordinate plane, and ℂ, the complex plane.

Every number in ℂ can be written in the form a + bi, where a and b are elements of ℝ², and i, the imaginary number, is an element of ℂ.

As you can see, elements in the complex plane consist of both real and imaginary parts. But elements in the real plane have only real parts and no complex/imaginary parts.

So, how does this relate to aromanticism?

Let's consider platonic vs romantic attraction. For me and many other aros, we don't experience romantic attraction. And for most allos, they experience both romantic and platonic attraction.

So what if platonic attraction was the real plane and romantic attraction was the complex plane. This would suggest that people in ℝ² experience only platonic attraction but have no grasp of what romantic attraction feels like. This also shows how allos in ℂ experience both platonic and romantic attraction, given how complex numbers contain both real and imaginary parts.

This is probably a massive oversimplification and I know this doesn't account for aplatonic and loveless aros but this analogy really helped me grasp why I don't get romantic attraction.

And so, my username is Latin: haesi perpetuo in ℝ².

Forever stuck in ℝ².

In my previous post, I demonstrated how any fixed image of a certain size centred on the origin can be deformed and repeated in arbitrary regions of the complex plane by the action of the Riemann zeta function.

In practice, for each point, s, in the relevant region of the complex plane, ζ(s) is calculated. If the real and imaginary parts of ζ(s) are within the bounds of the area covered by the fixed image, the colour of the pixel at the {x,y} value {Re(ζ(s), Im( ζ(s))} can be used to colour the pixel at s.

If the fixed image is a high resolution image of the iteration fractal of the Riemann zeta function, we can avoid iterating every point, s, in the target region of the complex plane by using the fixed image as a "lookup table".

Here is the resultant plot for the region of the complex plane covering -2 Re(s) < 5 and 80 < Im(s) < 100 at a resolution of 100 pixels per unit. The image has been rotated clockwise by 90° such that the imaginary axis runs from left to right. The image is derived from a 5001 x 5001 pixel fixed image "lookup table" whose points, f, are in the following ranges: -25 < Re(f) < 25 and -25 Im(f) < 25, also at a resolution of 100 pixels per unit:

-2 < Re(s) < 5, -80 < Im(s) < 100, 100 pixels per unit

It is clear that, for values of s where Re(s) > 0, there is insufficient resolution in the lookup table to give decent resolution in the final image. In the positive real half plane, the value of ζ(s) tends to 1. On that basis, it makes sense to increase the resolution of the lookup table close to the pole of the Riemann zeta function at f = 1.

However, given that the resolution in the rest of the generated image is reasonable, there is no need to create a very large lookup table with a resolution of, say, 1000 pixels per unit. Instead, we can create a series of "nested" lookup tables of increasing resolution centred on the pole, and programmatically decide which to consult after the value of ζ(s) has been calculated.

Here is the resultant plot for same region of the complex plane as above, but derived from a series of four 5001 x 5001 pixel fixed image lookup tables whose points, f, are centred over the pole and which have resolutions of 100, 1000, 10000 and 100000 pixels per unit:

-2 < Re(s) < 5, -80 < Im(s) < 100, 100 pixels per unit

The resolution of the region where Re(s) > 0 is much improved.

Here are the fixed image lookup tables used to generate the above image. Note that they are all centred on the pole at f = 1:

-24.0 < Re(f) < 26.0, -25.0 < Im(f) < 25.0, 100 pixels per unit

-1.50 < Re(f) < 3.50, -2.50 < Im(f) < 2.50, 1000 pixels per unit

0.75 < Re(f) < 1.25, -0.25 < Im(f) < 0.25, 10000 pixels per unit

0.975 < Re(f) < 1.025, -0.025 < Im(f) < 0.025, 100000 pixels per unit

These tables are good for images where Re(s) < 16. Experiments suggest that a further fixed image lookup table with a resolution of 1000000 can extend the scope even further into the positive real half plane. However, I am typically interested in fractal images confined to the region where -2 < Re(s) < 5, so I tend to use only the above four fixed image lookup tables.

Another obvious limitation of using fixed image lookup tables to avoid formal iteration of each point, s, is that the values of ζ(s) where Re(s) < 0 are far too large to be accommodated by any reasonable lookup table. Pixels outside the bounds of the lowest resolution lookup table are therefore coloured black.

However, one aspect of these regions is that iteration is not very costly programmatically provided that appropriate bail-out limits are applied. The vast majority of points in this region blow-up on iteration, and they do so quickly.

Therefore, because only a few iterations are required for the majority of pixels outside the bounds of the lookup tables, it is a trivial matter to provide a function which enables the user to choose to formally iterate any pixel that falls outside the bounds of the lookup tables in order to "fill in" the black regions without too much impact on resolution time.

Here are some resultant images with and without fill in:

-2 < Re(s) < 5, 80 < Im(s) < 100, 100 pixels per unit, without fill-in

-2 < Re(s) < 5, 80 < Im(s) < 100, 100 pixels per unit, with fill-in

-2 < Re(s) < 5, 980 < Im(s) < 1000, 100 pixels per unit, without fill-in

-2 < Re(s) < 5, 980 < Im(s) < 1000, 100 pixels per unit, with fill-in

-2 < Re(s) < 5, 9980 < Im(s) < 10000, 100 pixels per unit, without fill-in

-2 < Re(s) < 5, 9980 < Im(s) < 10000, 100 pixels per unit, with fill-in

-2 < Re(s) < 5, 99980 < Im(s) < 100000, 100 pixels per unit, without fill-in

-2 < Re(s) < 5, 99980 < Im(s) < 100000, 100 pixels per unit, with fill-in

-2 < Re(s) < 5, 999980 < Im(s) < 1000000, 100 pixels per unit, without fill-in

-2 < Re(s) < 5, 999980 < Im(s) < 1000000, 100 pixels per unit, with fill-in

Using fixed image lookup tables leads to a reasonable speed up in rendering performance and good reproducibility. The resultant images are essentially indistinguishable from those generated by zeta_machine.

Here are a few pretty variations of the complex sine function. 

Polynominals are eigenforms if seen as recursive functions.

Coefficients are eigenvectors because they change the scale/intensity.

Exponentiation scale value within a row.

The square root of negatives shift value to another axis.

I get Quaternions (you can also have negatives of exponentials i, j, k...).

Polynominals are symmetry groups with marked row.

The complex plane (and Quaternions, Octonions) are symmetry groups with a marked axis.

The independent variable is the input, the dependent variable is the output.

A symmetry group is a struct.

A symmetry group with pre-available shifts is an object.