Inspired by the recent post on Crosscut, I started thinking about geometric programming, and what it might look like. I came up with the idea of using areas and line segments of 2D shapes as inputs and outputs. For example, a rectangle gives us addition (the half circumference), multiplication (the area), square root (using area as an input and measuring one of the sides): (image 1) One could imagine an iteration construct ala the one in Bret Victors computational drawing program, or similar to the one in Crosscut, that allowed expressing e.g. Fibonacci iteratively: (image 2) Here the green arrows connect inputs lines to output lines, and the dots show where line segments begin and end. The dotted rectangles represent iteration, where the first rectangle is used to specify the relation to previous rectangles (exactly how is a bit vague, I know). The green line sets the distance between each iteration. Similarly, a unit circle could show the angle as a bent line (in radians, as the circumference is 2*pi), and sin/cos as shown. Using sin/cos as inputs and measuring the bent line you get asin and acos: (image 3) Thoughts? Maybe it already exists?

Hey, this is pretty cool! Whenever thinking about geometrically constructing math formulae, I like to reference the section Constructing Reals from Rudy Rucker's wonderful book Infinity and the Mind — https://www.rudyrucker.com/infinityandthemind/#calibre_link-318

It's important to ask whether the geometric representations you use actually contribute to understanding. Take your Fibonacci example. I don't think representing addition as the half-perimeter of a rectangle provides me with any intuition or insight here. To me, this particular diagram would be better off if you just stacked the input segments to form the output segment. Better still might be a Fibonacci spiral construction, as shown below. No clue (offhand) how to represent this construction in a programming system, but it says a lot more, geometrically, than half-perimeters of rectangles /or/ stacked segments.

Yeah, that's something we ran into with Crosscut and didn't really engage with. The freedom to draw "whatever" at the concrete level is really pleasing; being able to manipulate the "whatever" using a dynamic system is appealing. But having vector math be the only way to do that dynamic manipulation is such a narrow channel through which to work — it's very unlikely to match the character of the "whatever" you drew. I'd like to lean away from geometric representation entirely. That means no vector math — probably no math at all. I want to see what that dynamic / programming system might look like.

@Ivan Reese I don't know if I can even conceive of that kind of system. If its not vector math, and it's not geometric representations I don't know what you would have left.