Chaos overhaul (new branch)

[katestange]

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.

This PR overhauls Chaos, changing it to P5GL and changing the par ameters to mostly formulas.

This should eventually resolve #518 #447 #384 #317 #539

Still to do:

• Checkbox to enter static mode (no zoom/pan, unlimited iterations)
• Formula to compute the updated point, defaulting to lerp from current to target point.
• update snapshots
• put images in the documentation
• featured specimens
• corner label placement (see below)
• whether to use TWO_PI or TAU in the code (see below)
• See if the significant performance degradation for e.g. 30,000 corners when showing labels can be fixed.
• test errors

[katestange]

See #540 for previous comments on the development of this.

[katestange]

A possible featured specimen to try out: http://localhost:5173/?name=Phoenix+Rising&viz=Chaos&corners=12&walkers=3&sizeFormula=0.6&colorFormula=rainbow%28w*360%2FW%2B65%29.brighten%281%29&pixelsPerFrame=100&seq=OEIS+A000005

[gwhitney]

Three comments so far:

1. We discussed it earlier, but did you want to either add a parameter for the radius of the circle that the corners are on (so that you can conceptually zoom in without having to use the zoom) or start the camera farther out the z-axis and adjust everything else, so that you can zoom in further before you hit the "screen goes blank because I've flown through the plane containing the dots" problem?
2. Also/instead do something to prevent "flying through", such as switch to some geometric sequence of distances to the plane containing the dots, that never flies through?
3. In the screenshot below, you can see that when the corners are labeled, the relationship between the vertex location and where the number is placed does not seem uniform. I think it should be possible to place the numbers more accurately.

[gwhitney]

3. In the screenshot below, you can see that when the corners are labeled, the relationship between the vertex location and where the number is placed does not seem uniform.

And when you resize to a very small screen height, numbers to the top are clipped, and the numbers seem much larger than they need to be:

[gwhitney]

The "Divisor Square" specimen does not seem to be updated for the revised visualizer. Perhaps that's implicit in the unchecked "featured specimen" box at the top.

[gwhitney]

http://localhost:5173/?name=Phoenix+Rising&viz=Chaos&corners=12&walkers=3&sizeFormula=0.6&colorFormula=rainbow%28w*360%2FW%2B65%29.brighten%281%29&pixelsPerFrame=100&seq=OEIS+A000005

Does the name refer to the embedded orange-red Sierpinski triangle? It is pretty, but not more so than Divisor Square and it's not clear to me it's worth having two featured specimens based on the same A000005 sequence... and I would say DivisorSquare has a somewhat better "Change Sequence" tableau. Isn't there some Chaos instance showing a bias in the distribution of primes among residue classes to some modulus? Would that make a good specimen?

[gwhitney]

OK, here's a pass through the docs and code. Given there's a bunch of items, I'll presumably make another pass when these are resolved. (Some may not need any changes.)

[katestange]

I've pushed most of the suggested code tweaks, so you can resolve many of them (if I didn't respond, I'm assuming it's ok and you'll probably resolve unless I misunderstood the guidance).

[katestange]

Also lint passes on my machine, I wonder if my lint is a different version?

[katestange]

But finally, I'm a bit frustrated with fade. After your comment that my suggestion of putting a translucent rectangle over the picture to fade was not "artificial", I added such a feature. Whether or not it is performant enough to keep it, it has highlighted some real issues going on.

I'm too tired to keep at it now, so if in the meantime you want to look at this URL:
http://localhost:5173/?name=Random+integers+0+to+9&viz=Chaos&corners=8&walkers=8&sizeFormula=5&pixelsPerFrame=20&fadeEffect=0.05&seq=Random&last=1000&length=1001
then you will see what I mean. With fade, you can clearly see that the chunking is doing something weird, with a "fast initial" phase followed by a slower behaviour with intermittent spasms. It's also eating up my computer, which should not be happening.

[katestange]

I reverted the change that broke compiling.

[gwhitney]

But finally, I'm a bit frustrated with fade. After your comment that my suggestion of putting a translucent rectangle over the picture to fade was not "artificial", I added such a feature. Whether or not it is performant enough to keep it, it has highlighted some real issues going on.

I'm too tired to keep at it now, so if in the meantime you want to look at this URL: http://localhost:5173/?name=Random+integers+0+to+9&viz=Chaos&corners=8&walkers=8&sizeFormula=5&pixelsPerFrame=20&fadeEffect=0.05&seq=Random&last=1000&length=1001 then you will see what I mean. With fade, you can clearly see that the chunking is doing something weird, with a "fast initial" phase followed by a slower behaviour with intermittent spasms. It's also eating up my computer, which should not be happening.

Yes, I see what you mean. I am tired at the moment too, so I will take another stab when I next get to this. I suspect the issue is that you are drawing the fade overlay every dot, as far as I can see. So it's adding a lot of polygons to the "chunks". Any chance you'd be content with just drawing one overlay per frame? That would "cluster" the fade levels, but I hypothesize it will reduce the processing burden significantly. I will give it a try sometime soon and if it looks OK to me, push it for you to try out and see what you think.

[gwhitney]

OK, there were some indexing difficulties that caused the fast initial phase followed by the slow period -- basically once there was at least one chunk, it was redrawing all the dots on every frame.

Now the difficulty is that when it makes the chunks, all of the dots in the chunk are at the same unfaded intensity, and then the chunks are re-drawn and don't get faded. So I will need to

(a) when making a chunk, for each dot, figure out how many times it would be faded, then draw it in its dot color faded that many times, and

(b) just before displaying each chunk, fade the number of times that would occur during the normal drawing of those dots.

Of course, all of these multiple fadings can be done by precomputing the proper derived color/opacity and fading once -- I just need to figure out the formulas.

[gwhitney]

All right, I have put in code for (a) and (b). It turns out there was a complication -- I had implemented the Chroma overlay function incorrectly, and I had used a poor definition of scalar multiplication: if we are going to define c + d for colors c and d to mean overlaying d on top of c, then we had better have c + 2*d = c + d + d (don't need parens, overlay is associative), or in other words, 2*d == d + d and 3*d == d + d + d etc. And then by the usual sorts of tricks like building up the reals from the naturals, you get what r*d has to mean for any real number r and color d. OK, so I switched to that definition for scalar multiplication. Then fading k times with color bg is just fading once with color k*bg, so it made that part very easy. And the situation has much improved. You can try your test URL above, it now looks totally fine. When you drag, it does temporarily brighten up because it now draws the entire thing in one frame, which means no fading for the last bunch of pixels, but I am not too fussed about that. The very old pixels are still differentially fainter, even when you do drag.

However, I have not quite gotten the fading completely smooth. For example, try this example of just watching three simultaneous more-or-less ordinary random walks on the integer lattice: http://localhost:5173/?name=ThreeStaggered&viz=Chaos&walkers=3&stepFormula=0.02&colorFormula=rainbow%28W*360%2Fh%29&pixelsPerFrame=3&fadeEffect=0.02&seq=Random&max=3 (I recommend you zoom in somewhat)

You will see that it fades out nicely, except that every now and then a bunch of the older stuff gets much lighter all at once. So on average, it seems to fade out about as rapidly as I'd expect, but it's jerky. I think it has to do with the chunking -- maybe I haven't quite gotten my counts of the number of fades in different circumstances consistent, or maybe there's still some issue in the fade formula -- possibly a numerical one, because the scalar multiplication formula does now involve raising the transparency ( = 1 - alpha) to the scalar power. So for a large scalar (lots of fades), we're visually comparing the result of that exponentiation done in floats, to the results of overdrawing that number of times on an eight-bit-per-channel graphics buffer. So maybe rounding issues in overdrawing the fade 30 times to 8-bit accuracy produces a significantly lesser fade than precomputing the effect of 30 fades in full 64-bit IEEE floating-point arithmetic. That would explain why I can't see the effect at larger fade rates, nor when there are more pixels per frame (= less frequent fades, since there is one fade per frame). The more I think about it and experiment, the more likely it seems that is what is going on. For example, if you take your sample URL above (not mine), and let it run to completion, and then drag it a bit but then stop moving the mouse with the button still down, you will see it fades out (because it keeps drawing more frames, and fades once each time, with nothing new being drawn because it has finished the sequence). But this fade out stops with a faint "ghost" of the pattern, and doesn't get any dimmer than that. I suspect because of 8-bit numerical issues in drawing the faint, just slightly opaque overlay over the very dim dots, it ends reaching a fixed point just shy of all channels equal to 0.

So that would suggest that the occasional discrete "dimmenings" in my example URL are actually good -- the fadeout of really old points is being profitably recalculated with greater accuracy.

So should we call the current situation victory, or pursue even greater smoothness of fading? The only way I can see to achieve that smoothness is to choose a "visibility window" of step serial numbers (based on the fading rate and number of pixelsPerFrame). The idea is that steps earlier than the window have gotten so faint that they don't matter anymore. Then on every frame, you re-draw every dot in the visibility window, with its color pre-scaled using the full floating-point accuracy, so that they fade with greater fidelity. I don't see any way to use chunks in this scheme, so even once we've implemented it (which seems like a fair amount of work), the drawing might just not be performant enough to use practically. So I'd be inclined to leave well enough alone as far as fade goes, unless the lack of smoothness in some cases like the random walks link I gave really undermines your goals for this feature.

Looking forward to your feedback and when it's next convenient we can regroup and decide what all else needs to happen with this PR to get it merged. Thanks!

[katestange]

Hi @gwhitney do you know how to move the fern up to the center of the canvas? I'd like to feature it.

[katestange]

Something strange is happening with Fade. Try this one: http://localhost:5173/?name=OEIS+A007931&viz=Chaos&corners=9&walkers=2&bgColor=4E8DA4FF&staticMode=true&eagernessFormula=0.16&sizeFormula=1.5&colorFormula=rainbow%28W*360%2Fh%2B140%29&pixelsPerFrame=10&fadeEffect=0.003&seq=OEIS+A007931
I don't think the background colour should be changing with fade?

[gwhitney]

Have reproduced weird background color/fade thing. It really is weird. If I change the color it doesn't happen, but it is reproducible via that URL. Trying to investigate, but am very confused.

[gwhitney]

It was rounding on fading again. It only happened when the values of the color channels were different enough and the fade was small enough that fading-with-rounding-to-8-bits changed some of the channel values but not all of them, distorting the hue. (When the fade got so small that it couldn't change any of the channel values, the effect went away). So I had to switch back to using the framebuffer even in static mode. The big cost saving from static mode is never redrawing all of the points and not creating chunks (we only ever create one framebuffer at a time, and are careful to discard any old ones), so it still seems to work reasonably OK, I mean not noticeably slower than without a FrameBuffer, and the hue anomalies are gone.

[gwhitney]

This centers the Barnsley fern pretty well for me: http://localhost:5173/?name=Chaos+Game&viz=Chaos&stepFormula=%28%28%5B0%2C0%3B0%2C.16%5D*%28a%3D%3D0%29+%2B+%5B.85%2C.04%3B-.04%2C.85%5D+*%28a%3E2%29+%2B+%5B.2%2C-.26%3B.23%2C.22%5D*%28a%3D%3D1%29+%2B++%5B-.15%2C.28%3B.26%2C.24%5D*%28a%3D%3D2%29%29*%28P%2B%5B0%2C200%5D%29%2F40+%2B+%5B0%2C1.6%5D*%28a%3D1+or+a%3E2%29+%2B+%5B0%2C.44%5D*%28a%3D%3D2%29%29*40+-+%5B0%2C200%5D&sizeFormula=0.5&colorFormula=%2300D132&colorChooser=00D132FF&seq=Random&max=7

[katestange]

Ok I don't have anything unpushed, so you could push the fix for fade?

[gwhitney]

Oh I thought I had, sorry. Will check what happened when I get back to my computer in an hour or two.

[gwhitney]

Oops yeah forgot the push. Should be OK now.

[katestange]

All checkboxes remaining on Chaos have been checked!

[gwhitney]

I think we are finally there :)