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

On 9/25/2016 6:30 PM, Christopher Kormanyos wrote:
>
>> 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:
> In my opinion, this is an interesting function.
> After a very quick look at the code, I noticed three potentialissues.
> 1) There are instances of constexpr commented outin the code. The macro BOOST_CONSTEXPR is availablein <boost/config.hpp>. This macro selects the appropriateversion of constexpr (or none at all) for the given compilerat compile time.
> 2) There is use of std::arrayin the code. I believe that one ofthe strengths of Boost.Math is compatibility with C++03.You might consider replacing <array> and std::arraywith <boost/array.hpp> and boost::array. This is because<array> and std::array are only available in C++11 or beyond.

You could also pretty easily use my CXX Dual library ( 
https://github.com/eldiener/cxx_dual.git) to use std::array when it is 
available, otherwise boost::array.

> 3) Testing is required for inclusion the the library.
> John might have more to say.
>
> Thank you for your interest, Chris.
>
>
>     On Sunday, September 25, 2016 2:33 PM, Balázs Cziráki <balazs.cziraki@gmail.com> 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.
>
> Best regards,
> Balázs Cziráki
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>