Show more

Comparison of white and pink noise. White noise has fairly constant spread, but energy increases exponentially with octave. Pink noise has farily constant energy per octave, but its spread increases towards lower octaves.

Process: for each overlapped windowed segment of audio input, compute energy/octave via Haar wavelet transform. Accumulate count, sum, sum of squared values. At the end of the input, ouput statistics: mean and standard deviation for each octave (normalized to mean 1). Compare output for different input. Think about how to make a classifier based on the output. Think hard about how to make this process differentiable and propagate discrimination results back to changes in the input.

brexit, demonstration 

Maybe a neural network is the wrong thing - for deep dreaming I just need a differentiable program, so I can propagate back to the input why it gave the output that it did.

yesterday I failed at making some drone music, just didn't turn out any good.

today I failed at training a neural network (trying to eventually do deep dream stuff for audio with a music vs speech discriminator - currently testing with sine wave vs white noise), just wouldn't work. possibly I had some matrix or other transposed or my architecture was fatally flawed or something else. the vanishing gradient problem bit me as part of this, output was effectively random as the earlier layers wouldn't get going.

wondering what I can fail at next week...

Got a button that switches the graphics display portion of my program, but I can't figure out how to set the Gtk Theme Variant at runtime within my code. My system is using a dark theme, and launching with GTK_THEME=:light seems to adjust it. Found some code from github.com/electron/electron/c but it doesn't seem to work (even after I adapted it to gdkx).

Dark theme. Soon to be made runtime switchable (instead of needing to find the bit in the source code, change it, and recompile).

Also dashed lines with a drop down to chose the pattern (not depicted in the attached image).

Got the asynchronous task list working. Now I can initiate many annotation tasks and continue zooming while they calculate in the background in as many threads as are available.

The overall GUI layout is bad at the moment (space around image, task list goes off screen without scroll bars, stretching the window, progress bars have tiny height) and the only algorithm I've ported to the new thread pool is Ray Out.

But it's a start.

Seems to work for doubly-embedded Julia sets, though it gets prohibitively slow without multi-core acceleration (~45mins to wait for the annotations on the attached, when it could take 3mins if all my cores were used in parallel). Image radius is about 1e-14, so not very deep, but tracing all those rays takes long.

Working on an asynchronous task queue with a worker pool now. I want each task to show up in the GUI when it is enqueued, with its own progress bar and cancel button; to be removed from GUI when it is done (when completed, it adds the annotation to the image, unless cancelled).

Ideally I will be able to continue interacting while tasks are running, enqueuing new tasks or even navigating to different locations. It remains to be seen whether I will need a priority system to make rendering more responsive.

✅ embedded Julia set filaments

It's a bit slow using only one core to trace all the rays in sequence. I should investigate a multithreaded task queue or something.

Automatic annotation progress update:
✅ child bulbs of a mu-unit
✅ filaments of a mu-unit (done, this post)
❎ child islands of a mu-unit
❎ embedded Julia set filaments (next on the list)
❎ embedded Julia set islands
❎ embedded Julia set hubs

Mu-unit is Robert Munafo's terminology: mrob.com/pub/muency/muunit.htm

claude boosted

I believe this will add up, boosts appreciated.

Medium:

Add a button to annotate the descendent child bulbs of a component.

Hard:

Make this button annotate the tuned islands too.

Medium:

Add rays, namely the periodic pair landing on the root, and pre-periodic pairs pruning the filaments.

status:
✅ first medium part done
❎ hard part needs a completely different approach
❎ second medium part is fairly straightforward, next on the list

The things I want to add to this week are varying in difficulty.

Hard:

Currently you can select an item in the annotation list on the right hand side of the user interface window, and it is highlighted in the fractal explorer window. But when you have a lot of annotations, trying to find a specific annotation gets tedious. So I want to make it so I can click in the explorer window and have it select the annotation in the list.

I think I can do this by drawing the annotations (using the library) into an off-screen buffer with anti-aliasing turned off and annotation ID values as colours. I'll probably draw the rays thicker than 1 pixel in this buffer, otherwise selecting will be a nightmare. I already have one off-screen buffer used for text collision/overlap avoidance (aka dynamic level of detail), I might be able to reuse it. Ray sort order should be by (preperiod+period) (lowest drawn last / on top) to be intuitive, text b-boxes on top.

Medium:

Add a button to annotate an embedded Julia set automatically, because marking all those points and rays is a bit boring.

Easy:

Add a number box for hiding rays whose (preperiod+period) is higher than this threshold, as a stop-gap until I figure out how to choose this threshold (or another way to prune rays) automatically.

archive.org/details/ZIMMER162
[ZIMMER162] Bebhionn - System III
(cc-by-nc-nd)

some nice minimal techno, maybe too minimal for dedicated listening but it's nicely accompanying my coding today

I fixed the crash (race condition caused by freeing something in the wrong (non-GTK) thread), and improved the sort ordering too.

Also added an automatic dynamic level of detail feature for the annotations, so when you zoom out you don't get a mess of unreadable overlapping text. Not perfect yet (the rays still bunch up heavily) but better than before.

on (derivative distributions may also work, other distros may need tweaks). Installs into ~/opt by default, you can change that with make options (e.g. `make -C c/lib install prefix=~/fantastic-software/`).

```
sudo apt install git build-essential libpari-dev libmpc-dev libgtk-3-dev libsndfile-dev libglfw3-dev libglew-dev
mkdir -p ~/opt/src
cd ~/opt/src/
git clone code.mathr.co.uk/mandelbrot-sy
git clone code.mathr.co.uk/mandelbrot-nu
git clone code.mathr.co.uk/mandelbrot-pe
cd ~/opt/src/mandelbrot-symbolics
make -C c/lib/ install
make -C c/bin/ install
cd ~/opt/src/mandelbrot-numerics
make -C c/lib/ install
make -C c/bin/ install
cd ~/opt/src/mandelbrot-perturbator
make -C c/lib/ install
make -C c/bin/ install
cd
LD_LIBRARY_PATH=~/opt/lib ~/opt/bin/m-perturbator-gtk
```

I tested the build process in a chroot (which grew to 1.2GB), but I haven't figured out how to run graphical applications from a chroot yet.

Uploaded a 10min silent of me operating my `m-perturbator-gtk` GUI for exploring and annotating the set. There are still some annoying bugs (annotation sorting/ordering is mildly inconvenient, sometimes it crashes when zooming which is a big big pain as there is no autosave yet).

1080p video link (43MB):
mathr.co.uk/mandelbrot/2019-10

This version of the program has some local changes to the code from my public repositories, will push soon.

Ordering rays to see how to construct the tip rays (one letter inside ()) from their neighbouring hub rays (five letters inside ()).
```
. O(o) -- one lo
. O(o o o o i)
.(O) -- central lo
.(I) -- central hi
. I o o o o(i) -- five lo
. I o o o i(o) -- five hi
. I(o o o i o)
. I o o o(i) -- four lo
. I o o i(o) -- four hi
. I(o o i o o)
. I o o(i) -- three lo
. I o i(o) -- three hi
. I(o i o o o)
. I o(i) -- two lo
. I i(o) -- two hi
. I(i o o o o)
. I(i) -- one hi
```
The pattern seems to be "match longest prefix of neighbouring hub rays, then append o(i) and i(o). Except for spoke five. Needs to be verified for other locations, just in case it is a fluke.

This is reminiscent of my 2013 blog posts about in the set:

navigating by spokes: mathr.co.uk/blog/2013-02-01_na
> The tip of each spoke is the longest matching prefix of neighbouring angles, with 1 appended.

islands in the hairs:
mathr.co.uk/blog/2013-10-02_is
> Actually, a finite binary expansion is really an infinite binary expansion, ending in an infinite string of 0s. But there's another infinite binary expansion for each number ending in infinite 0s, that ends in an infinite string of 1s: .xyz1000... = .xyz0111...

By the tuning algorithm 1(0) and 0(1) become i(o) and o(i), I suppose.

Trying to analyse the patterns in the external angles of hubs heading towards the other tips of the spokes:

```
-- influencing island p4
o = .(0011)
i = .(0100)
-- central island p29
O = .(00110011001100110100001100111)
I = .(00110011001100110100001101000)
-- bulb 1/5
b = .(00001)
B = .(00010)
-- main inner hub
.O(ooooi)
.I(oooio)
.I(ooioo)
.I(oiooo)
.I(ioooo)
-- spoke one (towards inner tip)
.O(o)
.I(i)
.Oo(ooooi)
.Ii(oooio)
.Ii(ooioo)
.Ii(oiooo)
.Ii(ioooo)
-- spoke two
.Io(i)
.Ii(o)
.Ioi(oooio)
.Ioi(ooioo)
.Ioi(oiooo)
.Ioi(ioooo)
.Iio(ooooi)
-- spoke three
.Ioo(i)
.Ioi(o)
.Iooi(oooio)
.Iooi(ooioo)
.Iooi(oiooo)
.Iooi(ioooo)
.Ioio(ooooi)
-- spoke four
.Iooo(i)
.Iooi(o)
.Ioooi(oooio)
.Ioooi(ooioo)
.Ioooi(oiooo)
.Ioooi(ioooo)
.Iooio(ooooi)
-- spoke five (towards central island)
.Ioooo(i)
.Ioooi(o)
.Oooooi(oooio)
.Oooooi(ooioo)
.Iooooi(oiooo)
.Iooooi(ioooo)
.Ioooio(ooooi)
```

Spoke one is discussed in the previous post in this thread.

Spokes two, three, four seem to be something like: if the last part of the periodic part of the hub is i (resp. o) take the preperiodic part of the tip with periodic part (i) (resp. (o)) and append o (resp. i) combining with the periodic part of the hub.

Continuing along a spoke in the same direction means going along spoke one of each next hub.

Spoke five needs more thought.

Show more
post.lurk.org

Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.