Now in geometric algebra we also have oriented basis vectors. So they determine the unit, and the direction of the embedding space (note that this not necessarily map directly to points in your world space, which becomes especially clear when you start doing projective geometry, e.g. in 3D PGA you represent lines in your world as planes in the embedding space). Rather than xunit, yunit, etc, they are simply called e1, e2, ..., en.

The key difference is that geometric algebra has the exterior product, notated ^. For example, e1 ^ e2 is the exterior product of two oriented basis vectors. You can interpret this as being an oriented basis for the space spanned by e1, e2. And similarly for e1 ^ e2 ^ e3 being an oriented basis of the volume spanned by e1, e2, e3, etc. These are called basis blades.

The most general closed numerical representation of an object in geometric algebra is the multivector. Just like a traditional vector is just a bag of K coefficients for K basis vectors, a multivector is a bag of 2^K coefficients for the 2^K basis blades, one for each possible combination of the exterior product of the K basis vectors.

The concept of a coordinate system is not ambiguous. You have dimensions, and each can be represented as a vector that complies with specific properties, such as linear independence.

> Which cardinal direction map to x, y, z respectively (e.g. is z for up/down or forwards/backwards)?

That's a function of whatever coordinate transformation you wish to apply.

Nevertheless, I vaguely recall from school the concept of an oriented vector space and direct coordinate system, whose definition was something like the cross product of consecutive director vectors resulted in a positive vector (right-hand rule) i.e., the direction of z is determined unambiguously by the direction of x and y.

> Now in geometric algebra we also have oriented basis vectors.

If I'm not mistaken, oriented referential systems are covered in intro to euclidean geometry classes.

> The key difference is that geometric algebra has the exterior product, notated ^. For example, e1 ^ e2 is the exterior product of two oriented basis vectors. You can interpret this as being an oriented basis for the space spanned by e1, e2. And similarly for e1 ^ e2 ^ e3 being an oriented basis of the volume spanned by e1, e2, e3, etc. These are called basis blades.

Sounds like a convoluted way to refer to basic concepts like direction vectors of a direct coordinate system.

Quite bluntly, this all sounds like an attempt to reinvent euclidean geometry following a convoluted way. I mean, what does all this buy you that applying a subset of affine transformations (scaling, translation, rotation) to an orthogonal coordinate system doesn't give you already?

It is attempting to reinvent Euclidean geometry, yes. I don't think it's convoluted though.

To give a prime example, take the article we're commenting on: interpolating rotations. Or more generally: interpolating transformations. Just doing this with rotations without suffering gimbal locks already brings you to quaternions. Are quaternions 'convoluted'?

The fact that all objects are native to the algebra means they're composable. Take for example this slide of the formula of a 4D torus in coordinates, and in 4D PGA: https://i.imgur.com/T4hofL2.png The talk in general has a bunch of example applications: https://youtu.be/tX4H_ctggYo?t=4232

Questions such as "the intersection of this line and this plane", "the line through two points" "the circle where these two spheres intersect", "the point at the intersection of three planes", "the projection of this line on this plane" and such are trivial, native (the resulting object is part of the algebra) and exception-free in geometric algebra. E.g. two planes always intersect, it just happens that the intersection is a line at infinity if they're parallel.

The exact same code used to translate and rotate a point around the origin can be used to translate and rotate a line, or a plane around the origin.

Also note that most of computer graphics already realizes that embedding our geometric space into a larger space is useful. Projective geometry (embedding 3D into 4D) is already everywhere, because it unifies translations and rotations into a single concept (matrix multiplication). Geometric algebra simply goes a step further.

I think that's the idea.

> I mean, what does all this buy you that applying a subset of affine transformations (scaling, translation, rotation) to an orthogonal coordinate system doesn't give you already?

Well, algebra: with the geometric product one can solve geometric equations in a nice, unified way.

Hang on, is that a Natural number, or a signed Integer? Is it place-value, and if so what's the base? Big- or little-endian?

Is it fractional, and if so is it a rational (numerator and denominator), or fixed-point (what precision?), or float (how big's the mantissa?); maybe it's a unum? How about a sequence of continued fractions?

This is tongue-in-cheek; but from a software perspective, all those representations have the same "API" (arithmetic). Likewise, geometric algebra is an "API"; that's essentially what an algebra is.

I fail to see how that makes any sense. OP clearly referred to the unidimensional nature of a scalar in contrast to the n-dimensional nature of a vector, or the n*m-dimensional nature of a matrix. It makes no sense to try to go off on a tangent regarding, say, the resolution of a scalar representation. Perhaps the concept of a ray gets halfway there. Perhaps the concept of a line at infinity.

The concept of a scalar is familiar, as is the concept of a vector. Using the terms "scalar with a direction" to describe a vector makes no sense if you come from that starting point. Perhaps magnitude+direction vector rings a bell, because that's also a basic description of a vector.

Perhaps the author made a mistake, or does not have a good math background, or is filing in his knowledge gaps by coming up with definitions . Or perhaps he's actually referring to different concepts that the readership is not familiar. Who knows?

> This is tongue-in-cheek; but from a software perspective, all those representations have the same "API" (arithmetic).

This assertion is quite wrong. Both scalar and vector, in this context, are data types. Describing a data types as a data type of a data type is meaningless and does not compute.

> Using the terms "scalar with a direction" to describe a vector makes no sense if you come from that starting point.

Now I'm confused: what is a vector, if not a "scalar with a direction" (or indeed "an oriented scalar value", as the parent quoted)?

> Both scalar and vector, in this context, are data types. Describing a data types as a data type of a data type is meaningless and does not compute.

I disagree; "scalar value" is an interface, supporting addition, multiplication, negation, etc. (e.g. https://hackage.haskell.org/package/base-4.16.1.0/docs/Prelu... https://smlfamily.github.io/Basis/real.html ). Many data structures can implement this interface (Float, Double, Rational, Fixed, Nat, Int, etc.).

Likewise, "vector" is an interface, supporting vector addition, scalar multiplication, and (crucially in this context) inner, wedge and geometric products. Many data structures can implement this interface (e.g. a tuple of scalars, as coefficient of a fixed orthonormal basis; a scalar length paired with angular spreads projected in fixed perpendicular planes; etc.)