laszlokorte

I think the best introduction is by taking the geometric perspective: Addition is translation, multiplication with a positive number is scaling, multiplication with -1 is reflecting across the origin, multiplication with any negative number is scaling and reflecting at once. multiplying with a square root of a positive number does only part(half) of the scaling. multiplying twice with the square root does the full scaling.

Now the only question left is: what is the half of a reflection? a 90 degree rotation into a new dimension. Doing it twice returns to the original dimension but on the opposite side of the origin.

This also explains why division of 0 is a problem: multiplying by 0 scales everything to the origin (ie deletes the original size). Division would need to restore the original size. But as a sibling comment has already said. Division by zero could just scale everything to infinity. But then everything can only flip between 0 and infinity.

In your example 3 and 2 belong to different dimensions. you could write "3x + 2y" to express 3 steps along the x axis and 2 along the y axis. Just writing "3+2" would lead to the expectation that 5 could be calculated as reasonable result, which would not be the case.

In rust this would simply be

   enum ConnectionStste {
        Connected(u32),
        Disconnected
    }

Yeah I would have expected it to only decide which button to press, not something abstract like the choice of "go east to lavender town" for the goal of "in lavender town, climb the pokemon tower"

What I do not understand with the "languages do not matter"/"frameworks do not matter" is ultimately the following:

What a good language or a good library (and to a lesser degree also a good framework) does is to pre-compress ideas into well understandable and composable chunks.

Examples:

`printf("foo %d, %3.2f %s", ...)` abstracts/compresses a general strategy of shuffling bytes into the correct ascii/utf-8... format. An LLM could also write the raw assembly or bytecode for doing the same thing, but for one it would take much more tokens and to apply this pre-invented concept, and second without the concept already invented there would be no "information pattern" in existence that the LLM could have learned or refer to.

`list.map(...).filter(...)...` are patterns that (when applied strictly in a functional sense) go hand in hand with laws like `map` not affecting the number of elements, and filter producing no new elements etc... These are also patterns that are already invented and depending on the language these restrictions are checked. Just reading `map` somewhere can tell you (and the LLM) a lot, and writing `map` instead of while, for or jmp will capture and express much more information. LLMs would not have been able to learn these concepts if they did not already exist. And even if such a general pattern would be discovered by an LLM somewhere inside its learnt parameters, it would not haven given this pattern a name that it could/would tell you. And if you do not know the name for such a concept how have a much harder time prompting the LLM.

Expressing computations in a well understood algebra allows for symbolic manipulation and simplification. like `5 + 3 == 3 * 5 == (1+1+1) * 5 == (5+5+5)...`. But algebraic manipulation requires a symbolic language with precise rules to describe what manipulation is allowed. In AI-speak you could say the language itself is a harness or a sandbox to guide and restrict whats possible. Doing advanced math proofs is only possible for LLMs because languages like LEAN provide a strict guideline to build upon.

In short, two extremes: If LEAN is so great at proofing correctness and LLMs are so good at LEAN, why is not from today on everything (windows, linux, basecamp, hey, gcc, rustc, blender...) translated into LEAN? Why bother with rust at all? On the other hand if languages do not matter anyway and LLMs are able to recognize all the pattern on their own, why not let the LLM output and iterate on the binary bytecode to generate a self contained binary directly?

Maybe prefer-reduced-motion?

I have now added an extra section about higher dimensions.

I have now reworked the colors and labels.

Thank you very much! Those are all very good points I agree with. Reworking the color scheme is something I had already planned.

Oh, you are right. My 3d example is bad indeed. Thanks for pointing it out.

I think my mistake from the very beginning was to frame „reflection“ as happening around a vector instead of around a plane. I did this because I thought of it to be easier to vidualize. The I carried it on into 3d but as you say it does not generalize.

Had I started with doing reflections across planes I think it might generalize correctly across dimensions.

I have to admit this kind of mistake might completely undermine the correctness and usefulness of the visualization. I will rework this. Glad you noticed it.

As soon as you stop mimicing