Define exp(UnitQuaternion{T}(0, 0, 0, 0)) = one(UnitQuaternion{T})

[bzinberg]

As currently written, exp(UnitQuaternion{Float64}(0, 0, 0, 0)) evaluates to UnitQuaternion(NaN, NaN, NaN, NaN). Upon initial thought, I think it's mathematically "correct" to special-case this behavior (i.e. when the argument is exactly zero) and define the result to be the identity quaternion. We're applying the exponential map to zero, viewed as an element of the Lie algebra of unit quaternions, and the result should be the identity element of the Lie group. WDYT?

[tkoolen]

I'm mostly just a bystander at this point, butUnitQuaternion{Float64}(0, 0, 0, 0) already evaluates to all-NaNs and

We're applying the exponential map to zero, viewed as an element of the Lie algebra of unit quaternions

is not really true, since an all-zeros UnitQuaternion (which must have been constructed by explicitly skipping normalization in the constructor) is not mathematically a unit quaternion. It seems strange to introduce complexity and possibly reduce performance for this case.

[bzinberg]

I agree that it's weird that "logs of unit quaternions" are expressed using the same data type as the unit quaternions themselves, but AFAICS, that is how the code is currently written. The zero I was referring to is an element of the Lie algebra (not the Lie group). Exp of it gives you a quaternion but it's not one -- and this is true not just of the zero Lie algebra element but also of all other logs-of-quaternions. Concretely, the line

Rotations.jl/src/unitquaternion.jl

Line 246 in 2b7404c

M = es*sθ/θ

computes an expression containing sin(θ) / θ, which is NaN, but that is a removable point discontinuity, and AFAICS there is one clear choice for its value. I.m.o., the more complex version is the one that doesn't do the mathematically natural thing (so it all boils down to what the mathematically natural thing is 🙂).

This showed up when I was doing SLERP interpolation, with q^t = exp(t * log(q)), and saw weird behavior that I tracked down to be occurring when t was zero in a particular code path.

Good point on performance loss -- would that be due to a run-time check whether the input equals zero?

[bzinberg]

The code change I'm proposing is something like #127.

[bzinberg]

UnitQuaternion{Float64}(0, 0, 0, 0) already evaluates to all-NaNs

Ah, I did not realize that. 0 * UnitQuaternion{Float64}(1, 0, 0, 0) produces the non-NaN value I would have expected to be created by that call to the constructor.

[tkoolen]

I agree that it's weird that "logs of unit quaternions" are expressed using the same data type as the unit quaternions themselves

Ah, I was somehow thinking of log instead of exp because of the quaternion argument. Yeah, that is weird. I agree with your statement in #30.

[hyrodium]

We now have RotationGenerator with #203.

julia> exp(RotationVecGenerator(0.,0.,0.)) == one(QuatRotation)
true

This issue seems resolved.