# LambertW has no series expansion at x=0 (nan) #7259

Open
opened this Issue Mar 10, 2014 · 13 comments

Projects
None yet
7 participants

### mforbes commented Mar 10, 2014

 With sympy version 0.7.5: >>> series(LambertW(x),x) nan This is probably due to the chosen representation of the derivative >>> LambertW(x).diff(x) LambertW(x)/(x*(LambertW(x) + 1)) which requires a 0/0 limiting form with numerator LambertW(x), which requires the derivative at 0 which has a limiting form of 0/0 and so on... One mathematical solution is to replace x = LambertW(x)*exp(LambertW(x)) in the derivative 1/(LambertW(x) + 1)/exp(LambertW(x)) which may be safely evaluated at x=0 where W(0) = 0. Not sure if this type of thing is easy to do in the code though.

### mforbes commented Mar 10, 2014

 For testing, the answer should be: LambertW(x) = x - x**2 + 3/2*x**3 - 8/3*x**4 + 125/24 * x**5 + O(x**6)
Member

### asmeurer commented Mar 11, 2014

 Changing the derivative like that would break the integration algorithm, which relies on the derivative being a rational function of the original expression. One fix would be to finally make heurisch use its own separate form of the derivative if it is available (there was an issue for this somewhere already, but I can't find it). This would also let us do things like make tan(x).diff(x) give the more expected sec(x)**2 rather than 1 + tan(x)**2. It's probably also possible to make this work without modifying the form of the derivative, by setting some other method that is called by the series function. I don't know how that stuff works too much to say, though.

Member

### asmeurer commented Mar 11, 2014

 So if you are interested in fixing it, you would: Change LambertW._eval_derivative to give the output you mentioned (it may also be implemented as fdiff). Add LambertW._eval_heurisch_derivative Modify heurisch to check for _eval_heurisch_derivative if it exists instead of the normal diff. Fix tests that are just the different form of the expression. Add tests for the series of LambertW Hopefully no other tests will fail because of the change, other than the ones that test the derivative itself. The only way to know is to try the change and run the tests.

### czhao86 commented Mar 16, 2014

 In functions/elementary/exponential.py, change return LambertW(x)/(x*(1 + LambertW(x))) to return 1-2*x+3/2*3*x**2-8/3*4*x**3+125/24*5*x**4 seems to be fine. Or is it too simple?

### mforbes commented Mar 16, 2014

 @czhao86 No: the series approximation is only an approximation. There are infinitely many terms that have been ommitted.

### czhao86 commented Mar 17, 2014

 I see... So the returned function should not be changed. Could you tell me where is the series function? Under sympy/series/series.py, there is nothing. Thanks. PS: I just find it under sympy/core/expr.py. Nevermind...

### chaserelock commented Mar 18, 2014

 I have solved this issue and will be issuing a pull request as soon as I've written some more tests and thoroughly verified everything is working as planned (looks like it so far). I now have the heurisch algorithm check to see if a specific heurisch derivative exists in the function's class, otherwise it will revert to the exact same process it had before. I also added the case for the LambertW function and I am able to both evaluate the series around x=0 and the integral.

### chaserelock commented Mar 18, 2014

 This is the testing results without my new tests in it, I wanted to make sure the printing errors were just because I'm lacking those packages. I believe my fixes also closed some old issues that had been expecting to fail: ____________________________________________________ xpassed tests ____________________________________________________ sympy\core\tests\test_args.py: test_as_coeff_add sympy\integrals\tests\test_failing_integrals.py: test_issue_1135 sympy\integrals\tests\test_failing_integrals.py: test_issue_1393 sympy\integrals\tests\test_integrals.py: test_evalf_issue_939 sympy\integrals\tests\test_integrals.py: test_integrate_derivatives sympy\integrals\tests\test_integrals.py: test_issue_1304_2 sympy\stats\tests\test_continuous_rv.py: test_uniform_P sympy\utilities\tests\test_module_imports.py: test_module_imports_are_direct ______________________ sympy\interactive\tests\test_ipythonprinting.py:test_print_builtin_option ______________________ File "c:\python27\lib\site-packages\sympy\interactive\tests\test_ipythonprinting.py", line 68, in test_print_builtin_o ption assert text in ("{pi: 3.14, n_i: 3}", u('{n\u1d62: 3, \u03c0: 3.14}')) AssertionError ________________________ sympy\physics\vector\tests\test_printing.py:test_vector_pretty_print _________________________ File "c:\python27\lib\site-packages\sympy\physics\vector\tests\test_printing.py", line 42, in test_vector_pretty_print assert expected == pp.doprint(v) AssertionError ________________________ sympy\physics\vector\tests\test_printing.py:test_dyadic_pretty_print _________________________ File "c:\python27\lib\site-packages\sympy\physics\vector\tests\test_printing.py", line 138, in test_dyadic_pretty_prin t assert expected == result AssertionError tests finished: 5484 passed, 3 failed, 119 skipped, 342 expected to fail, 8 expected to fail but passed, in 1761.15 seconds DO NOT COMMIT! PS C:\Users\Chase\Documents\GitHub\sympy\bin>
Member

### asmeurer commented Mar 18, 2014

 Those errors are unrelated, and possibly fixed already (you can try to merge with the latest master if you want). Just send the pull request and see if the Travis tests pass.

### chaserelock commented Mar 19, 2014

 It seems that the hardcoded fdiff's in trigonometric particularly do not have the chain rule written in. So in the case of arguments having coefficients, there were some errors. I'm going to get as much of that tidied up as I can before I send it.

Closed

Contributor

### lennart0901 commented Oct 27, 2014

 As chaserelock did not answer for quite a long time I took a shot...

Open

### klemvor commented Dec 25, 2014

 Since the expansion around z=0 of the Lamber W function is known (see the Nist page about the Lambert W function) can't we just use the explicit form of the taylor series using the taylor_term?

Open

Open

Contributor

### cbm755 commented Feb 10, 2017

 After #10531 is done, we may be able to cherry-pick here.