On 2016.09.25. 19:11, John Maddock wrote:
We have an open bug report for this which I've just updated to point to your code, plus Thomas Lui's revised version from his thesis: https://svn.boost.org/trac/boost/ticket/11027.
Yes, that is a fairly simple implementation, its using only one type of initial approximation and after that it keeps applying Householder's method to approximate. I tried to use as many types of initial approximations as I could to select the ideal one for a certain range (or area in the case of complex numbers). I've also found that Householder's method tends to overflow using floating point arithmetic for large numbers and use Newton's method combined with Fritsch's iteration that is specific to the Lambert W function instead. I'm working on a documentation, it will have all this information in detail.
* Are the only permitted values for k 0 and -1: the two solutions of the equation? If so it doesn't really make sense to me to have this as a function parameter in that case, would it not be easier and more streamlined to have two separate functions for the two solutions?
That is only the case for real return values, for complex values k could be any integer.
* Where possible I'd much prefer additions to Boost.Math to be agnostic of the number type - ie to work with user-defined types such as those from Boost.Multiprecision. We have some guidance for submissions here: http://www.boost.org/doc/libs/1_61_0/libs/math/doc/html/math_toolkit/special... which I hope is a lot easier to follow in practice than it initially looks: honest ;)
I'll try to look into that. I initially tried to write it without presuming number type, but gave up in the end.
* Given that the real valued functions are rather easy/lightweight to implement, does it make sense to dispatch to separate real valued and complex implementations right from the start? If so we have boost::is_complex.
Since calculating the complex and real values is a very similar process (initial approximation -> a few Newton's iterations -> one Fritsch iteration) with almost identical formulas I've decided that developing the complex versions alongside the real versions is the most efficient.
* I'm rather conflicted about the use of C++14 in the code - I appreciate it's the current standard, however, given how easy it would be to support C++03 and the same functionality, I'm not sure what if anything this gains us?
Initially this used variable templates to store contants but since then I've worked around that. The current one on GitHub should only require C++11. Going below that would require working around the absence of the std::array container. I've wrote this library so it could (mostly) calculate it's own constants, and that is why it uses that container. Thanks for the feedback, Balázs Cziráki