(hilbert-curve 0 0 800 0 0 800 5)
[#]clojure
=> More informations about this toot | More toots from jack@berlin.social
@jack I haven't forgotten this 🙂
Where's this algorithm from? Closest I could find to it was https://dl.acm.org/doi/10.1145/290200.290219
@neauoire @qualmist
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from akkartik@merveilles.town
@akkartik @neauoire @qualmist From? I improvised it while live coding 🤷🏻♂️
=> More informations about this toot | More toots from jack@berlin.social
@jack 🤯 I need to think about why this algorithm is the same as the L-system based version in Wikipedia.
(Who needs eso-langs, computing is plenty esoteric to begin with.)
=> More informations about this toot | More toots from akkartik@merveilles.town
@akkartik @jack Two alternative versions that may aid your understanding... #1 chooses what I think are better variable names, since the xs & ys are mixed up in the original version. #2 uses vector operations. It would look a lot better with overloaded operators... but it's helpful anyway to see that the program is really operating on the vector level.
=> View attached media | View attached media
=> More informations about this toot | More toots from qualmist@assemblag.es
@qualmist Ahh, the first version in particular helps a lot! I still don't understand why it works, but at least I have more of an intuition now of what the variables are.
@jack
=> More informations about this toot | More toots from akkartik@merveilles.town
@akkartik @jack Cool! I can also use some human words and say: (x, y) is the top-left of the curve's square, (x1, y1) is a vector from the top-left to the bottom-left, and (x2, y2) is a vector from the top-left to the top-right. So you're taking a big square and sub-dividing it into smaller squares, in a particular order & with particular orientations.
=> More informations about this toot | More toots from qualmist@assemblag.es
@qualmist That does help. Do top/bottom/left/right rotate through the recursive calls?
@jack
=> More informations about this toot | More toots from akkartik@merveilles.town
@akkartik @jack yeah, they gotta for the ends of the curves to join up!
=> More informations about this toot | More toots from qualmist@assemblag.es
@qualmist @akkartik This implementation was hacked together while making this logo. The complete source for which is here:
https://github.com/nextjournal/clerk-demo/blob/main/notebooks/logo.clj
They are absolutely vector operations, but I was trying to make things brief without adding a dep on a vector lib. I couldn’t avoid vector multiply though. 😆
=> More informations about this toot | More toots from jack@berlin.social
(hilbert-curve 0 0 800 0 0 800 5)
@jack It's interesting that I get back jank if I replace the (... n 0 0 n ...) pattern with other possibilities.
Does the hilbert curve logo thing you made with curved lines start out from this version?
@qualmist
=> More informations about this toot | More toots from akkartik@merveilles.town
@jack Visualizing leaf calls. x, y in red, xi/yi/xj/yj in green.
@qualmist
=> More informations about this toot | More toots from akkartik@merveilles.town
@jack I better handle when the debug information collides.
@qualmist
=> More informations about this toot | More toots from akkartik@merveilles.town
@jack Even better, show which direction the base vs control points are used in.
@qualmist
=> More informations about this toot | More toots from akkartik@merveilles.town This content has been proxied by September (3851b).Proxy Information
text/gemini