> As a side note, Geometric Algebra contains more than just Rotors, and is a very useful tool to have in one's toolbox.
I worked in a game engine where a pair of mathy programmers fell in love with Geometric Algebra, and use this same argument that quarternions ought to be replaced to overhaul all of the math code in the engine using Geometric Algebra. The character rigging system removed matrices and used GA instead.
This caused several large problems in the code base:
For one, it slowed the code down a little because the GPU interface is all matrices, so there were conversions to matrices all over the place, rigging in particular.
And only two guys in the studio knew Geometric Algebra, and they didn’t invest time in teaching it or helping people understand it, they just hoisted it on everyone. All the rest of the programmers knew matrix math but not Geometric Algebra, so they would end up avoiding touching any of the GA code, i.e., any code that dealt in transformations. The two guys ended up with a lot of support of their own creation, but they were short with their answers, in part because they got so many questions, so the problem never went away.
The third problem is this whole rewrite was unnecessary. Fixing gimbal lock with quaternions is a tiny corner of the game engine, whereas using GA throughout is a massive rewrite. Matrices work really well for 98% of the code, and it’s not really a huge problem to have one or two routines that convert to quaternions and back while they do a rotation. It is a problem when any transform at all involves bivectors and rotors and you have no idea what the hell those are nor do you have time in your schedule to take a math class at work.
Personally, I’m intrigued by GA and have wanted to learn it for a while, but having used it in production, I’m mildly against replacing quaternions with GA, and very wildly against replacing matrices with GA.
I'm a former game engine lead from many years ago, from around the time that quaternions were becoming popular, since we never used them before the early 2000's, really, as 3D was young and rotation matrices sufficed.
Quaternions came into favor to solve the problem of gimbal lock in composed Euler rotation matrices. This happens when you create a rotation which rotates one axis into another, and end up with a matrix that loses one axis (it loses an eigenvector), and you become "trapped" in the new rotated frame and can't ever rotate out of it. Quaternions don't suffer from this problem, but they're also tricky to work with and reason about, and their rotations can become funny when composed - instead of rotating from orientation A to B, they'll go through a C in a very different place. You need to create heuristics to keep rotations looking sane with quaternions. In the games that I've worked on, we took other precautions to avoid gimbal lock in rotations and stuck to Euler matrices. For example, in a flight simulator, you always computed the final rotation matrix for the plane location directly from its heading, pitch and roll, and so, you'd never suffer gimbal lock.
Why stick to Euler matrices and not some better Geometric Algebra or Quaternions? Because it's really easy to interpolate, and think about plain old rotations about a vector, and you can teach anyone to avoid gimbal lock. It's easier to avoid that problem than to train a bunch of junior engineers on higher level math.
Quaternions are also quite a bit more efficient (both in flops especially when composing rotations frequently) as well as storage space (4 values in a quaternion vs. 9 in a 3D rotation matrix).
It's interesting to compare disciplines, since I've never worked on a game engine but have done a lot of simulation of physical systems: there, quaternions have been standard for at least fifteen years, and I've seen geometric algebra frequently for about the past five.
Interestingly, where we saw most gains from thinking about geometric algebra wasn't in simple rotations, but when starting to look at things like computing kinematic chains composed of dozens of joints: Now we're at 4x4 matrices to store each transformation, which is the traditional way and works well. From this, some seriously deranged mathematicians introduced the concept of an eight-element dual quaternion (essentially, pair of quaternions specially constructed) that can represent this. Again, super efficient, but even more intractable for newcomers than quaternions. At this point, starting to express both concepts in terms of geometric algebra has been able to keep most of the performance improvements as well as only having to teach one concept.
When I left that position a year ago, we were starting to see recent graduates that already had pre-exposure to geometric algebra concepts before even starting to work on the codebase.
Could you elaborate more on interpolation and weirdness of composing quaternions? I thought a big selling point for quaternions was the ease and naturalness of just using slerp, whereas with euler angles a similar approach gives bad results. When you mention rotations about a vector, do you mean you decompose the desired rotation matrix into axis/angle? Otherwise I'm very impressed by your ability to visualize compositions of arbitrary rotations.
You can't solve the problem of avoiding gimbal lock in arbitrary rotations, so you rig the game not to ever have arbitrary rotations. You cheat, basically. Gimbal lock is a huge problem in software where free form rotations are allowed, such as 3D modeling packages, CAD, but in games, since we control the world, we can set it up not to have these problems.
Quaternion interpolation works well, but it introduces twist, which is sometimes not what you expect. When you start composing many quaterions, you get some wild rotations, going the long way, or doing an additional 360 twist, and whatnot. Mind you, I'm digging 20 years back in my brain here, I don't remember many specifics anymore.
There are a number of problems with your assessment in modern day engine design I think.
First, because of IK, we cannot control orientations exactly. Newer techniques like motion matching/IK can generate new orientations on-the-fly, depending on what a character is doing and the character's environment. Gimbal lock matters for camera movement as well. Looking up with Euler angles is a great way to induce a seizure if not done correctly.
Second, the "wild rotations" you mention has a very simple solution employed by every engine I've worked with. Basically, you just constrain the real part to be positive which fixes your interpolation on one half of the Lie-manifold which ensures the arc taken is as short as possible.
Gimbal lock is a problem for euler angle representation of rotations, not rotation matrices themselves. You can fix it for euler angles the same way they used to for old mechanical gimbal gyroscopes. By having a fourth rotation of the frame that points the singularity out of the way. This is a typical solution in navigation for dealing with the poles of the earth (a wander angle frame).
Wikipedia says that then the fourth one needs "to be driven" to stay perpendicular with the 1rst one (otherwise a "double-gimbal lock" would still be possible, I guess ?). And this "active driving" is likely to complicate the design even more ?
For sure for a real gimbal, I'm just saying that you can do the same thing mathematically to avoid singularities when dealing with rotations represented as euler angles.
As an engineering manager who's had to push adoption of new technologies, I feel this argument in my bones.
That said, taking your argument to the extreme, we all probably should've stuck with PHP, since everyone understood it and, well, was it really worth the switching cost? Naturally that's dumb, so there's a certain amount of "how do we get there?" with any new technology that's probably a good idea.
That's probably not going to get answered by the principal engineer who says This Tech Is The Future. It's going to get answered by people like you who think about switching costs and the impact new tech has on people.
> taking your argument to the extreme, we all probably should've stuck with PHP, since everyone understood it and, well, was it really worth the switching cost?
There are multiple paths for honing a new technology, without dumping it on a large group of developers while it's in its experimental stages:
- Use it for a series of side-projects
- Use it in a startup or startup-like team in which all the developers are bought into it, and happy to work through the obstacles
- Use it at an organization that's both able and willing to devote a large amount of resources to making it work (e.g. devoting a full-time team to its development & support & related training)
Once the kinks have been sufficiently worked out in one of those contexts, and a solid ecosystem with good documentation exists, then there's a much better chance that the benefits will be worth the switching costs for the average project.
I haven't worked on large gaming projects, but I've worked on large CG feature films. I was a little horrified about how aggressively they adopted some technologies. The theory was that Pixar proved a lot of their technologies in their short films (Disney a bit of that, too, in previous years). The studio I was at didn't do that and both Disney and Pixar seem to have moved away from that at least a decade ago. Very very rarely, they'd repurpose old projects or chose a sequence or specific department for releasing something--that often was a mess (resources spent at the "boundaries" instead of shoring up the new tech).
I imagine AAA games are similar. You have 4 years and ship one monolithic game. Maybe you could prove out this idea in a small area like artist's tools or an engine fork (similar to the approaches above). Trying to incrementally adopt something would take 2 or 4 games (10+ years) and I just don't see technology roadmaps like that. Especially if it's not a huge win.
I would hope any good principal engineer spends a decent amount of time considering switching costs and impacts of new technology. Sounds like this isn't your experience though?
These problems are not inherent of GA, but of (flawed) implementation details and deeper social problems. GA code boils down to essentially the same computations as 'raw' Linear Algebra, and should be implemented as such. Your math centered programmers fell in love with the idea without ever figuring out how to really use it.
I completely agree it wasn’t inherent to GA, but I wouldn’t summarize it as they didn’t figure out how to use it. They were fluent, the problem is the rest of us weren’t.
The problem with what they did, and what this article is doing, is suggesting we “fix” something that takes 2 or 3 math classes to understand by replacing it with something that takes an entire semester to understand.
I honestly believe that GA has insights to offer, but I don’t believe it will save any time to upgrade the use of quaternions in any 3d engine.
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.
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.
Right, as a physicist, this may be super naive but matrices are just representations of the underlying algebraic structure so I'm not sure why it isn't possible to merely do both once you've decided on a way to convert between the two.
Rotors in geometric algebra form a “double cover” of rotations, for example using unit quaternions there are two different quaternions (q and -q) which will map to the same rotation matrix. This means that mapping from rotation matrices to quaternions is a bit fraught - you need to pick a “side”, and if that side happens to be opposite to what another part of the code (perhaps the part only using quaternions) chose, you’ll get some whacky stuff happening. The same idea applies for geometric algebra.
I feel like this requires the same concern when replacing any system. Even if the new tool is better in theory, does it have enough people using it/experts working on it that it is better in practice and does the costs of replacing it justify the improvement.
Just look at something like a 50 year old IBM mainframe vs. the newest Sql Server with .Net Core running on the server of your choice. Is the latter the better choice for a new application? Yes. Yet many very successful businesses don't replace their mainframes because the benefits do not justify the costs.
Thanks for saying this. On other math topics on wikipedia, I've read, re-read, and re-read them and still felt like I didn't understand. Maybe it wasn't all my fault.
I think the Wikipedia math articles are not horrible, if you already know the concepts involved and just need a bit of a reminder on something. If you don't know them, though, they're not a good way to learn, IMHO.
I've multiple times heard mathematicians says Wikipedia math pages are bad, and even experts in an area can be confused by the pissing of other experts in that same area.
This is more or less the thing with "Category Theory".
Very fancy and neatly structured code but in the end you accomplish pretty much the same; and now nobody on the team understands a bit about what you're doing.
Whats going on here is you're scoffing at something you don't understand. Before you scoff, understand it. Then scoff. Until then you're just as good as the ignorant people who ridiculed the theory of a heliocentric solar system.
Nice preconceptions, they truly add to your argument.
CT brings nothing new to the table in terms of "now we can do X that we couldn't do otherwise". If you can provide an example to prove its usefulness, please do. Funny thing is that every time it comes down to "just show me" the hand-waving and "you wouldn't get it" begins. Things that work speak for themselves.
>you're scoffing at something you don't understand
Actually ... I was also very excited by the promise of CT a few years ago and since then I have read a lot about it and I'm quite confident "I understand" what I'm talking about. I've been programming for about 20 years, half of them with functional languages (or languages with first-class functional constructs: lisp, haskell, scala). I have read the most famous books on CT touching on programming, some of them are signed as I have spent my own money going to some CT conferences and meeting with the people there.
As a conclusion, I don't mean that CT is useless in itself. It definitely is a nice mathematical framework and has proven a great tool for a few things here and there in different areas of math. But in the context of computer science, as I said it before, it does not bring anything new to the table.
But they also scoff at things that never take over the world. So it doesn't actually mean that it's ahead of its time. It could be an overcomplicated mess that you don't actually need, and it could to be that forever.
I'm not sure where you're getting this. moralestapia never said he didn't understand it. (In fact, in a parallel branch of the comment tree, he said that he did understand it.) He said that if you use category theory on a project, now nobody on your team understands the code. But that "you" probably doesn't mean "if you are on my team and do that, I won't understand it". It probably means more like "if one uses category theory", that is, if you use it on your team, this is the result, if I use it on my team, the same result happens.
And if you mean dahart, he said (or at least implied) that he didn't understand geometric algebra, but he didn't say anything about understanding category theory.
My email recorded a more hostile version of your original comment before you edited it. I will post it here:
>moralestapia never said he didn't understand it. In fact, in a parallel branch of the comment tree, he said that he did understand it. Your post is at best a misreading of what he said, and at worst a deliberate slander.
I don't like comments that accuse me of slander, even as a possibility.
I'm going to be frank with you. HN is a big place with thousands of users, I never encounter the same user twice... but you seem to appear regularly out of nowhere and reply to my comments. I may be wrong and that you happen to be just everywhere but your responses seem like you're just hunting me down to reply to me.
If you are doing that please stop. Additionally I just don't like you or care for your opinions in general because of the above hostility. So even if you aren't creeping around just to reply to my comments, I'd appreciate it, if the next time you see my name just ignore the comment and move on. My comments are not addressed to you and they have nothing to do with you.
Yes, that comment was too hostile, and I apologize. It was not up very long; I thought better of it almost immediately.
> ... but you seem to appear regularly out of nowhere and reply to my comments. I may be wrong and that you happen to be just everywhere but your responses seem like you're just hunting me down to reply to me.
Bluntly, I notice you most often by seeing a comment that I think is too harsh of a reply to someone else. I don't like it when I see that. (You complained about me doing so to you, with some justice, so you should understand the feeling.) I try to give you the benefit of the doubt, because I have the impression that English is not your first language. But it seems to me that you often interpret peoples' words in a very negative way, which their actual words do not seem to me to deserve. I get annoyed when people do that (not just you). I try to speak up when I see people getting grief that they didn't deserve (again, not just when you're involved).
> So even if you aren't creeping around just to reply to my comments, I'd appreciate it, if the next time you see my name just ignore the comment and move on. My comments are not addressed to you and they have nothing to do with you.
Post on a public forum, get public replies. If you post here, you don't get to control who can reply and who can't.
Imagine you're in a public place and some stranger is following you around and replying to your comments constantly day in and day out. It's annoying and creepy af.
I can't order you to back off. But imagine this. You are approaching me every day in a public place and I turn and face you and I tell you to back off. This is the level of threat you are inciting. Your presence is not welcome and the environment is now extremely hostile. I can't call the police on you in a forum but if this were a public place it would be justified.
I am telling you to back off. It's your choice whether you do so, but I ask you to check your actions and really think about what you are starting here.
I find it highly unlikely that you are just coincidentally encountering me all the time out of nowhere. I'm dead serious. I don't like you, I don't care for your comments, back off.
I am not deliberately following you on HN. I find you mostly on threads about computer languages; I visit a number of other topics, whenever I find them interesting.
I am not trying to harass you or stalk you. But I'm going to keep reading what interests me. If I see what you wrote and I think it's wrong, I'm going to reply. If that upsets you, I'm sorry that you're upset, but I do not consider that reason for me to change what I read or who I reply to.
The one thing I can offer is that I will try to be careful not to over-react when I reply to you. I'll try to be careful to be moderate in my words.
> I can't call the police on you in a forum but if this were a public place it would be justified.
Even here, you can email dang if you think I'm seriously out of line. Feel free to do so if you think it's justified. I'm completely serious. If I actually am at fault, I easily may fail to see it in myself. If dang thinks that it warrants telling me to back off, I will take that very seriously.
I'll tentatively believe you for now that you aren't stalking me. But you are borderline creeping me the hell out.
>If dang thinks that it warrants telling me to back off, I will take that very seriously.
Are you serious? The person that is feeling harassed is telling you to back off and you are getting in his face and saying let dang decide? I don't think you're serious if you are actually inviting me to escalate this issue. If you reply to any one of my other posts I definitely will request his aid to moderate. BACK OFF.
His initial post said the "team" doesn't understand it so I took it to encompass "him" as part of the team. My post is in response to that.
Clearly his subsequent post says he does understand CT so I'm in error on that part.
Either way the "team" not understanding it, does not preclude it from being right. CT does not overcomplicate things. It just allows you to understand a program differently so you can decompose your program into smaller pieces or take a different path.
Saying CT complicates things is like saying number theory complicates numbers. Number theory is numbers and CT looks very much like a good theoretical framework for program organization. In other words CT looks like a formal theory for the design of programs.
We aren't at a spot where we can concretely say this, but practitioners of CT and programming are enamored with CT because it looks this way.
Overall, his complaints point to a lack of understanding despite his claim.
GPUs don't have dedicated matrix hardware anymore, making it questionable whether you really need to convert your GA structures to matrices first. [1] finds that quaternions are faster than matrices on modern hardware; I find that questionable, but it at least shows that they are comparable.
The APIs (D3D, etc.) do use matrices, and that's all that matters from the point of view of an engine developer. Composing quats together is certainly faster than composing matrices, but quats are limited (no translation / skew / perspectivce / etc.), so there is no direct apples-to-apples comparison between quats and mats.
D3D API exposes a way to pass constant buffers to shaders. You can pass whatever you want there, even integers. There're couple limitations, size must be multiple of 16 bytes, and can't exceed 64kb, but I don't remember anything specific to matrices.
Now, the only place I can remember which specifically targets matrices - mul intrinsic in HLSL. But that thing is just a syntactic sugar, usually compiling into dp4 dxbc instructions.
They let you upload matrix data to the gpu, but all functions like glUniformMatrix4fv() really do is upload a 16-vector into gpu memory (and optionally reshuffle its layout). The shading languages also have matrix primitives, that's just sugar.
Foisted is indeed a better choice there, whatever I thought I meant. Thanks! I thought about editing, but I’ll leave it so as not to disturb your comment.
That's not about "not being ready", the GPU really doesn't care whether the numbers it is multiplying are coefficients of a matrix or a bivector.
The problem is that all libraries, drivers, etc. use matrices, quaternions and vectors. So you would have to constantly convert back and forth, which is both error-prone and a non-trivial performance problem.
Of course, you could build your own libraries for everything, but that's just crazy. Who has time for doing that?
Not to mention that writing a mathematical library like that is a highly non-trivial task. Not just the algebra part but also numerical stability and accuracy are a big deal. That requires a very skilled person, naive implementations will rapidly blow up in your face.
And doing all this what for, exactly? So that the GA explanation of rotations doesn't require 4 dimensions while the math complexity of rotor algebra ends up being the same as with quaternions? So there isn't really a performance benefit neither.
Who has time for that? Me. And, presumably, Marc ten Bosch. When you want to make a game that uses full 4D graphics, existing libraries just don't cut it, and writing GPU code to understand arbitrary-dimensional rotors is worth it.
The main issue here is that they tried to port what sounds like a mature code base. Imagine changing programming languages! They should have restarted from scratch, and with a team fluent in Geometric Algebra...
OK, after refreshing my memory on GA, it seems that one of the nice things about it is that you don't have to think about the "row" vs "column" vectors present in "Vector Algebra". Which are usually represented in the form of matrices.
But you don't "need" them in GA, since you can directly work with vectors (= arrays) !
(Which makes it even more curious as to why matrices would be more efficient for 3D work ??)
I think I understand roughly what you mean when you distinguish row and column vectors. For example, let [x, y] represent a row vector and [x, y]^T represent a column vector.
If you have a function f that maps [x, y]^T -> z, (you might write it z=f(x,y)), then the gradient(f) is a function [x, y]^T -> [x, y]. That is to say, the gradient is a row vector. It's a different kind of vector than the input to f. And it transforms different (c.f. https://math.stackexchange.com/a/3200912/)
As you say, Geometric Algebra doesn't talk about row vectors and column vectors. For example, in 3D GA,you can choose a representation in R^8. That's 1 scalar, 1 pseudo-scalar, 3 column-y components, and 3 row-y components.
lol, ok - so then it's more the opposite - in GA there are row an column "vectors" (3-components)... but they are not "enough" (for that R^8 representation), so a matrix representation might be misleading ?
From reading a lot of comments it seems like misinformation. One thing worth keeping in mind is that game developers are highly risk averse. For good reason.
Isn't the data structure that supports quaternions just one dimension up from matrices? Why not continue using matrices and retain that last dimension seperately somehow? Then it doesn't require having to retool the GPU/matrix side of it.
IE you will have multiple matrices where you would have had one otherwise.
I worked in a game engine where a pair of mathy programmers fell in love with Geometric Algebra, and use this same argument that quarternions ought to be replaced to overhaul all of the math code in the engine using Geometric Algebra. The character rigging system removed matrices and used GA instead.
This caused several large problems in the code base:
For one, it slowed the code down a little because the GPU interface is all matrices, so there were conversions to matrices all over the place, rigging in particular.
And only two guys in the studio knew Geometric Algebra, and they didn’t invest time in teaching it or helping people understand it, they just hoisted it on everyone. All the rest of the programmers knew matrix math but not Geometric Algebra, so they would end up avoiding touching any of the GA code, i.e., any code that dealt in transformations. The two guys ended up with a lot of support of their own creation, but they were short with their answers, in part because they got so many questions, so the problem never went away.
The third problem is this whole rewrite was unnecessary. Fixing gimbal lock with quaternions is a tiny corner of the game engine, whereas using GA throughout is a massive rewrite. Matrices work really well for 98% of the code, and it’s not really a huge problem to have one or two routines that convert to quaternions and back while they do a rotation. It is a problem when any transform at all involves bivectors and rotors and you have no idea what the hell those are nor do you have time in your schedule to take a math class at work.
Personally, I’m intrigued by GA and have wanted to learn it for a while, but having used it in production, I’m mildly against replacing quaternions with GA, and very wildly against replacing matrices with GA.