@vpisarev Please take a look.

@chargerKong, the introduced operations are potentially dangerous, because there is no way to guarantee that "S" is scalar value, and it's not "cv::Scalar", "cv::Rect", "cv::Mat" etc. To resolve possible ambiguity, I suggest to add the following operations instead:

     template <typename T>
     friend Quat<T> cv::operator-(double, const Quat<T>&);

     template <typename T>
     friend Quat<T> cv::operator-(const Quat<T>&, double);

     template <typename T>
     friend Quat<T> cv::operator+(double, const Quat<T>&);

     template <typename T>
     friend Quat<T> cv::operator+(const Quat<T>&, double);

     template <typename T>
     friend Quat<T> cv::operator*(double, const Quat<T>&);

If needed, add the same operations for float scalar.

Thank you for your code review @vpisarev.

If "S" is not float or double or int, the implemetation of these functions will finally raise an error, because we have limited the elements for generating quaternion must be float or double. So I think maybe it's OK.

@chargerKong, right, but from our experience with template functions in OpenCV this is still a potential problem.

OK.

I have one last question.

What if we add some limitation in these funcition? @vpisarev

template <typename T, typename S>
inline Quat<T> operator+(const S a, const Quat<T>& q)
{
    static_assert(std::is_same<S, int>::value ||                 	   
                   std::is_same<S, double>::value ||                                                          
                   std::is_same<S, float>::value , "A quaternion only can be added with a scalar or a quaternion.");
    return Quat<T>(q.w + a, q.x, q.y, q.z);
}

IMHO, to avoid unclear operations (without documentation) it is better to introduce .addRotation() method (rotate() function) instead (due to angle/2 behavior and normalization tricks).

Thanks for your code review @alalek

I want to stick to use these operators and could add the documentation in detail. Because these kind of operations are easy to read and understand. This is the symbols which we have used in papers and the daily writing by hand.

What do you think?

@chargerKong, if such a static_assert passes buildbot, i.e. compiles with every compiler that we use now, this is good solution.

Also, can you please add into the regression test at least one case where double scalar is added to floating-point quaternion, e.g. 1.3 + Quatf(1.f, 1.f, 1.f, 1.f)? I expect that some compilers will produce warnings for such operation because of missing type casts in the constructor calls.

<typename T, typename S>

IMHO, both types should be equal.

BTW, int => float conversion is not accurate.int support should be removed too.

I agree with @alalek, and we could add the note: "The type of the scalar and the quaterinion should be equal" in the documentation.
What do you think about it? @vpisarev

@chargerKong, it's fine with me, it will also automatically eliminate my concerns about possible ambiguity in the future

👍

@chargerKong, could you, please, squash the commits into one:

$ git reset --soft HEAD~2
$ git commit
$ git push --force origin

thank you!