exp(u*θ), where u is the rotor of a quatvec, does not return a rotor

[empet]

using Quaternionic
import StaticArrays:SVector
v = SVector(1,-2,3)
u = (rotor∘quatvec)(v)
q = exp(u*pi/6)
typeof(q)
   QuaternionF64 (alias for Quaternion{Float64})

I'm using the Quaternionic, 4.4.0.

[moble]

Yes, that's correct. For type stability, the return type has to be based on the input type, rather than the input value. In general, a Rotor can have a nonzero scalar part, in which case its exponential would have non-unit norm, which means that it can't be a Rotor; it has to be a general Quaternion. The fact that in this particular case the Rotor u happens to have a zero scalar component should not affect the return type, or performance would be negatively impacted, as the Julia runtime would have to constantly check what types it's working with.

[BTW, you don't need SVector at all for this example; quatvec(1,-2,3) works just fine.]

I try to make the types compatible with normal geometric usage, and I don't really know what u is supposed to represent here, other than a rotation through exactly π radians about the direction specified by v — but then I don't know why you would ever exponentiate that. (Mathematically, a QuatVec represents an element of the Lie algebra. Exponentiating such a thing maps it into the Lie group, elements of which are represented by Rotors. But there is no standard notion of an exponential of a Lie group element. So this operation doesn't really make sense.) Maybe you're just using rotor as a convenient way to normalize the QuatVec, but that would be better done using Quaternionic.normalize (which is just a re-exported LinearAlgebra.normalize) which returns a QuatVec with unit norm:

using Quaternionic
v = quatvec(1,-2,3)
u = normalize(v)
q = exp(u*pi/6)
typeof(q)
# RotorF64 (alias for Rotor{Float64})