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: Balázs Cziráki (balazs.cziraki_at_[hidden])
Date: 2016-09-25 13:58:49

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_tut.html
> 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