Re: [boost] [Math/Special Functions] Is there any interest in the Lambert W function?

Subject: Re: [boost] [Math/Special Functions] Is there any interest in the Lambert W function?
From: John Maddock (jz.maddock_at_[hidden])
Date: 2016-09-25 13:11:55

On 25/09/2016 12:27, Balázs Cziráki wrote:
> Greetings!
>
> I'm working on a C++ implementation of the Lambert W
> (a.k.a. product logarithm or Omega function) and I wanted to ask
> the Boost developer community if there is interest in adding it to the 
> library.
>
> The current version can be found on GitHub:
>
> https://github.com/CzB404/lambert_w/
>
> I've successfully tested it with Cygwin GCC v5.4, v6.2
> and with MinGW GCC that is supplied with Code::Blocks,
> and also on Visual Studio 2015.
> A test on a Linux based OS (probably Ubuntu) is also going to happen.
>
> Any suggestions or constructive criticism is welcome.

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.

At first glance:

* Your version looks a lot more complex than Thomas', however you 
support more used cases than he does.
* 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?
* 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_tut.html 
which I hope is a lot easier to follow in practice than it initially 
looks: honest ;)
* 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.
* 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?
* I haven't had a chance to test or examine your implementation in 
detail, I'm just sort of taking it for granted that it works ;)  But yes 
there is interest in this function.

Best, John.