Added support for dual quaternions (or planar quaternions, poincare, etc) representing "360 translations"

[hamishtodd1]

What this is

These ~4 lines of code deal with the case in PGA/CGA/STAC/STAP where you have two blades representing ordinary finite objects, say:
A = e12
B = e12+4e02 or -e12-4e02
And you want the translation from one to the other. So you take sqrt(A/B) like everyone tells you to. Problem is, A/B could be say -1+4e01. This is an object called a 360 translation. It's a translation together with a rotation by 360 degrees.

The "right" thing to do in this situation, from an engineering standpoint, is crystal clear. You, the user of the library, wanted the sqrt, not of the multivector, but of the multivector's negation. That'll be a translation from one object towards the other. Reminder that this is the primary use of sqrt for beginners and indeed most experts!

What is the right thing to do mathematically? This is a deeper question, though it seems to interest nobody except me. Well, fuck it, I learned pull requests to write this so here we go. If R is a 360 translation, the facts are these:

• In Cl(1,0,1) or Cl(2,0,1) there exist no objects r such that rr = -1+4e01
• In 3D and beyond there exist many solutions to rr = -1+4e01! But there's a horrible "gotcha": all of those r involve a 180 turn. Want one of them? You have to make an arbitrary choice, of which axis to rotate around. We could choose the one through the origin, but that'll seem very, very arbitrary.
• So, what my code does is return an object r which does NOT satisfy rr = -1+4e01 but DOES satisfy it "up to sign", eg rr = 1-4e01, which until a few minutes ago you were thinking of as basically the same fucking transformation as -1+4e01. To put that more formally, we have (-1+4e01)² = (1-4e01)², so by an abuse of what-most-people-think-is-true-about-sqrt-anyway I can write √(-1+4e01) = √√((-1+4e01)²) = √√((1-4e01)²) = 1-2e01. That's what I propose to give people (and it's what they want!)

You might say that since there's never a uniquely awesome r such that rr = R, maybe the sqrt shouldn't pretend there is one. Eg, what I described above (and implemented!) as the "engineer's solution" is wrong. Maybe. But if so - there should at least be an error that acknowledges that what's gone wrong is a very specific, recognizable thing. And it should suggest the clear solution: negate the input.

Technical

Initially I tried fixing this at the "codegen" level but it didn't like me checking x.e < 0 which I suppose was what you were warning me about. But working at the multivector level, with a little isinstance check, seems fine.

Fun facts

-There's no natural choice for a square root of a 360 translation, but there is a natural choice for a cube root.
-We say that the balinese candle dance/wine glass trick illustrates the quaternions. But, that's not really true, unless (you are extremely good at holding the object in precisely the same position in 3D space. It's much more comfortable to rotate the object and slightly move it a little, which is to say, your hand's state is described by a dual quaternion, not a quaternion. That means: when you have rotated the mug/plate 360 degrees back to its original orientation, but with your arm kinked up, the orientation state is a 360 translation
-A 180 turn followed by a translation, eg all those horrible 3D-and-above solutions to rr = -1+4e01, have the form B+s*e0123 where B is a simple bivector. Charles Gunn calls these "180 screws" and they are interesting in that they are the "simplest" quadreflections. They are also the PGA duals of translations, in a weird way that swaps angle and distance around.
-So obviously these things are very "spinorial". The fact that they "square to a vector(translation) without being one seems suggestive to me.

More here https://hamishtodd1.substack.com/p/360-translations-the-strangest-objects