I'm not sure you are fully understanding the situation. What jessermeyer is saying is that it's possible to use GA as a language for describing geometric operatiins while continuing to implement them under the hood using old-fashioned vector algebra.

The major proponents of GA don't suggest doing this. I'm not an expert so I can't rule out the possibility that somebody, somewhere has done it successfully. Computer implementation of GA is still a research topic: http://geometry.mrao.cam.ac.uk/2016/11/ga-2016-lecture-7/

There is a very strong flavour in the computational GA literature of directly implementing the GA operations—not translating to vector algebra. jessermyers is expressing a minority opinion when he says "don't do that".

Finally (and this might be a bit rude) I'm dubious about your assessment of your coworkers fluency in GA. Maybe they seemed totally facile with the bits they knew. In general, though, non-speakers can't assess fluency (in any language, right?). Similarly, what are you actually saying when you say that you "believe" GA has insights to offer? What is that confidence/assessment based on?

Applying GA is an active research field—it's not something people attain practical mastery in, just yet.

> I'm dubious about your assessment of your coworkers fluency in GA.

I wouldn't call that rude so much as you making incorrect assumptions and jumping to conclusions on top of my story that is incomplete on details. It certainly would be better left out of your comment, as there's nothing to be gained from cross-examining my ability to assess whether they knew more GA than I did. They did, in fact, know more GA than I did. And while I'm framing myself as a GA noob, I've dabbled enough to know a bit about what I don't know.

> it's possible to use GA as a language for describing geometric operatiins while continuing to implement them under the hood using old-fashioned vector algebra.

You're missing my point. They did implement GA using linear algebra. They built classes for bivectors and rotors that use dot products and cross products under the hood.

Once there are classes for GA objects, and they get used in the code, then everyone else has to use them and know how to use them. You can't use GA without knowing the algebra of GA types.

The implementation of the GA objects is not the question here at all.

For the record, I'm not saying everyone should not implement GA this way. The major proponents of GA are typically academic, who are interested in its abstract properties of computation. In this setting, it's probably a reasonable approach. But this is a completely different problem than engineering a game-engine which strongly encodes constraints into its solution. It's more like plumbing than math.

In fact, the datapoint here is an argument against implementing GA in its general form to perform computations.

There is a world of difference between understanding the properties of a computation and wanting to turn a wrench.

It sounds like one shouldn't have expected much of these coworkers, or rather should have expected their error, given that the academics studying GA haven't found efficient compile-time translations for GA into a performant solution with matricies?

Yeah, beating implementations of matrices is a tall order at this point in history...

Similar to how electric engines are superior to ICE in many ways, but ICE has a century of optimization work already done to catch up to.

From my gloriously irrelevant position in this arm chair, I wonder whether there's enough extra oomph that comes from GA to justify the conversion cost and catch up to the existing optimized linear algebra environment.

Without knowing more context it's a bit hard to respond, but from what you said, it sounds like they wrote an abstraction layer above matrices that observed GA semantics, which required a lot of run-time conversion. This is a flawed implementation, especially for a game engine. It's like writing a v-table for matrices to support every general case when you only need 3 or 4 specific instances anywhere in your code.

Time spent -- You're probably right. For new technology, it's probably worth the research to see if code clarity is worthwhile...

Not necessarily on top of matrices... I can easily imagine a part of an engine working with GA and then having to translate back or forth to matrices whenever it needs to interact with another (outside) part of the system.

Translations like this are probably not a great idea in a game engine but I'm willing to be shown an example where it's the Thing You Want To Do.

Oh, yeah, it's a terrible thing to do, absolutely. All I'm saying is that you can have a perfectly consistent /component/ using GA, but if it's living in a larger ecosystem of matrix-based code, you're going to have to do these translations somewhere. (eg, we rewrote the camera compoent in GA, but the dudes doing grass modeling haven't converted.) You get an all-or-nothing problem: it's efficient if the whole codebase is using the same abstraction, but converting around between a bunch of abstractions will come with a cost.

Yeah, I don't work on codebases of that scale so I can't really comment knowingly of what cost it would take to move the whole parcel over the GA. Probably highly dependant on code / social org.