> finally there's the 5D conformal GA, which is supposed to not have all this nastiness, but it's hard to find anything resembing practical on it

Give Versor[0] a try. Implementation is fast, solid, with lots of example code. I'm no math genius, but it makes sense to me. The book Geometric Algebra for Computer Science was also helpful.

Pablo (Versor developer) has some nice videos and write-ups on it too.

That said, I totally agree that GA in general is WAY too abstract. I don't give a shit about the intricacies of the math, what I care about are access to geometric objects that behave normally, where it takes very little code to go from "this is what I want to do" to "okay, it's doing it." Make me a circle from these three points, then rotate it by this much about this line—that kind of thing. I want the simple stuff to be stupid simple, and so far, Versor has been sufficient.

[0] http://versor.mat.ucsb.edu/

Thanks for the tip. I'm working with by-hand/symbolic stuff, so Versor may not be exacly the thing for me, but I think I'll learn about CGA a lot better by looking at that implementation than research papers!

You are not wrong. Except I am not sure why anyone would call linear algebra “cumbersome” - it and the geometry of differential forms cover pretty much all the practical needs, leaving geometric algebra outside the mainstream applied mathematics.

The "cumbersomeness" for me is mainly the problematic handling of rotations, especially when they're not around the origin. For "numerical" stuff even those are easy enough (given you don't have to do something "fancy" like interpolate), but "symbolic" stuff gets unwieldly really fast.

I think you might like Foundations of Game Engine Development, Volume 1. (http://foundationsofgameenginedev.com/) It focuses on practical uses of Grassmann algebra and doesn't avoid doing real-world calculations with actual coordinates. It also doesn't dwell on extraneous theoretical material that isn't directly necessary for getting your work done. Source code is included for all the operations.

Doing rotations about arbitrary points in geometric algebra requires the use of dual quaternions, but I agree that virtually every presentation of that material is awful. I'm trying to change that.

As someone who's vaguely aware of the workings of GA but not sufficiently immersed to fully grok your piece, could I suggest that some concrete specification of "geometric antiproduct" would be useful?

Googling for that phrase turns up exactly one page :)

An integral is a “continuous sum.” A derivative, then, is an “anti-sum.” Now think about a “continuous product” instead of a sum. The inverse is “anti-product.” It only gets more interesting from there:

http://math2.org/math/paper/sect1-3.htm

(I know, right?)

What you wrote has nothing to do with Eric's geometric antiproduct.

Eric calls the dual vectors in a geometric algebra (or Grassmann algebra as he calls it) antivectors. See his presentation from GDC2012 around the middle:

>Instead of saying (n−1)-vector, we call these “antivectors”

http://www.terathon.com/gdc12_lengyel.pdf (also: https://youtu.be/WZApQkDBr5o?t=1673)

So e.g. in 3D bivectors would be antivectors, in 4D trivectors would be antivectors, etc. He also calls what's usually referred to as pseudoscalars antiscalars - that is, n-vectors in an n-dimensional geometric algebra.

The geometric antiproduct introduced in this article has a similar dual relationship with the geometric product: the geometric antiproduct acts on vectors the same way as the geometric product acts on antivectors. Around the end of the article he even writes that the whole algebraic structure is invariant under dualization (or "antization" :D ): you can map scalars to antiscalars, vectors to antivectors, etc. and the geometric product will be mapped to the geometric antiproduct, etc.

I'm pretty sure that use of the word "antiproduct" is unrelated to this use. Here, the "geometric antiproduct" is defined as the dual of the "geometric product". I haven't been paying much attention, but I hope (1) that there's some kind of lattice structure here, and (2) that both the product and the antiproduct have strong geometric intuitions.

> GA hasn't been picked up is that it actually isn't that great when you're out of the math theoryland

Personal anecdata: I regularly do like 3–4 pages of obnoxious scratchwork in terms of coordinates, get stuck, feel like I’ve probably made some trivial errors along the way, etc., experience deja vu, and then recast everything in GA.

Then the alternative work-through ends up taking like 3–5 lines of simple algebra, with a clear geometric interpretation for every step, and way less hassle.

This has now happened maybe a dozen times over the past few years. Maybe I’ll eventually learn better and start out in GA land.

I've made a similar experience. On a high-level it seems intriguing but when working practically, there seems to be very little documentation. Even for very mundane tasks like taking the geometric product of two multivectors. Also I realize that many write-ups use different conventions (especially for CGA) making it difficult to combine documentation.

But yeah, traditional Linear Algebra really sucks in comparison. It seems surreal that for some tasks in LA that require solving equations - e.g. with Gauss algorithm - can be solved straight forward. Also I've read that it can be run quite efficiently due to advances in GPU computing. At the moment I'm checking Grassmann.jl, this seems quite promising in terms of performance although it's probably less intuitive than Ganja.js

I agree with a lot of what you have said here about GAs ease of use for newcomers, people change notation continuously across papers and there is a lack of material to go from nice basic theory and examples to practical applications. I started using the Clifford package https://clifford.readthedocs.io/en/latest/ because it was one of the only GA libraries that actually had documentation (thanks to Alex Arsenovic) and I could work out how to use as well as interfacing with numpy and the rest of the scipy stack. Documentation across all libraries is definitely still a problem and the difficult learning curve is compounded by the fact that there are basically no undergrad courses on GA (I know of only one in the world atm at the BNU Brno taught by Petr Vasik) and most of the existing material is targeted at mathematicians or physicists. Leo Dorst's Geometric Algebra for computer science does attack a lot of practical problems and is definitely worth digging into, as are the various PhD theses which focus on GA (I like the ones of Rich Wareham, Andreas Aristodou and Pablo Colapinto a lot) and the book Geometric Algebra in Practice but generally we have no practical hackers guide to GA yet. To try and address the lack of available material I started working on adding example practical GA algorithm implementations to the Clifford python package as I have gone along in my PhD and these now almost all now sit in the clifford.tools submodule . Along with the Czech guys I have also been building some slide tutorials that people may find interesting ( https://slides.com/hugohadfield/cgapython ) and Eric Wieser and I are building some tutorials and starter packs for doing robot IK in CGA in python/cpp . Overall I think we are starting to get there with building tutorials and docs and the recent additions to the community of people who come from a professional software background has made an enormous difference to the tooling which in turn has made it much easier to get started with GA (see Steven De Keninck's Ganja.js, Utensil Song's work on Galgebra and Eric Wieser's improvement to Clifford). The problem of differing notation is still there and yet to be resolved, I have been trying to get people to come together and agree on something but lots of people have very strong opinions on how things should be done etc etc.. my opinion on all that is that it really doesn't matter what notation you use as long as it is self consistent and solves the problem you have at hand but this doesn't really help when it comes to introducing people to the field... overall I don't have a solution to the notation problem other than to try and encourage everyone I work with to use the same notation and to add caveats in different places on papers/tutorials saying where people in the field differ in notation. If anyone has suggestions (or additional tutorial pull requests :)) I'm all ears!

Oof my paragraph breaks really didn't come through there..

Use two blank lines or the breaks won’t show up in the post.