Happy New Year, ctsts = 2025: treeprint + svgo.

86 views
Skip to first unread message

bradley klee

unread,
Jan 11, 2025, 9:17:30 PM1/11/25
to golang-nuts
https://0x0.st/8-v7.pdf  (nothing malicious, just an embedded svg)

The code for this is not really worth showing, because it's a very ugly hack
grafting "svgo" on top of "treeprint". 

Special thanks anyways to ajstarks and xlab at github; although, did anyone
else have a problem installing "svgo" lately? Command line get did not work
for me, some error I couldn't yet understand. I ended up installing manually. 
Maybe because my version is the 18.1 served through linux apt?

Anyways, here's an example script for using treeprint that will help some
college students figure out how to move pointers around:


Suggestions about style or usage are welcome if necessary. If not, then you're
welcome to skip to the output:


This one is worth looking at for many reasons, but essentially it's just a nice
counter-example to the fractal structure of the tree found in Hofstadter's
book GEB ("Hofstadter's G sequence").

Fun stuff, and headed for a full length explanation built all on top of golang
calculations and figure drawing.

The calculations are where golang will beat competitors producing a lot of 
data and running into memory limitations rather than compute. 

For example, here is a mystery about the Fibonacci Word Fractal, which I've 
just recently gotten the first clue to solving:


This is the (filtered) output up to hitting memory constraint on kind of a 
cheap laptop with not much space:

[0 0 0] 
[1 0 1 0] 
[0 0 1 1 0 0] 
[1 0 1 1 0 1 1 0 1] 
[0 0 1 1 0 1 1 0 0 1 0 0 1 1] 
[1 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 1]

And then I guessed the next term would be:

[0 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0]

(Someone with a better computer might actually be able to just
check this editing one parameter in the script.)

This is a turns sequence. Using svg or even png, you can plot it, and
if you flip either the first bit, the last bit or both, it should become a 
fragment of the fractal curve seen here:


Based on the bit flipping property, I think it will be possible to prove
the irreducible missing words as follows: 

Some recursive construction builds these particular curve fragments,
which are known valid. Then bit flipping the ends is guaranteed to 
invalidate them.

However, that still falls short of explaining why these are the **only**
missing words, so I think this mystery will persist for a while.

I'm not asking for help. I'm not asking for anyone to go unemployed
to prove something about math. I'm not looking for jokes about who 
develops what, and who has a disability, etc. etc.

I've read the code of conduct. It sounds good to me depending on 
how seniority is leveraged for gatekeeping purposes.

If "Beginner Mind" is appreciated, then it might be possible for me 
to become a vocal golang user and contributor. We'll see.

If anyone wants to co-work with me, I'm open to making friends and 
writing papers, and I'm also looking for a job opportunity (resume / CV
available on request).

This Fibonacci proof is something frivolous and extra that's just now 
surfaced. In the paper I'm calling it an "Aperitivo". Some of my other 
project ideas are more substantial.



Thanks again for your time and efforts. Nice tools you have here.



Best wishes for 2025, 







--Brad












 

 








 




bradley klee

unread,
Jan 12, 2025, 1:27:16 PM1/12/25
to golang-nuts
> Some of my other project ideas are more substantial.

Checking the moon calendar here:


Tomorrow, the Ice Moon rises full in Gemini. After another half 
cycle it goes dark, and the snake loses its legs, so to speak.

In the meantime, here's another golang "count to 2025" calculation: 


If you run locally, it can produce 20K trees per second on a laptop. 
That's about the same rate as the article from the 80's, which I found 
after writing the decrement function (see hyperlinks in header).

This is a first attempt, so if anyone wants to point out flaws, feel
free to. Having an efficient successor (or predecessor) function 
is really a separate issue than getting an efficient, never-breaks 
canonicalizer. The canonicalizer is what matters more, imo.

Before doing this calculation I had never really thought about
minimal representations of trees. I guess it can just be a list
whose length is dimensionalized about equal to vertex count.

This is slightly different than the situation with graphs where
a matrix is necessary, and might need optimize for sparsity.

One of my tiling projects has a lot of interesting search tree 
data needing to be re-generated, canonicalized and published, 
so that's where I'm investigating growth options.
 

All the best,





--Brad













Reply all
Reply to author
Forward
0 new messages