#4156 generalized_lambert_w won't provide float solution

[Chris Gorman]

When trying to compute a generalized_lambert_w solution for

98*t + 1080*%e^(-t/10) - 1180

I need to

[Chris Gorman]

Let me try to finish my bug report here...

Sorry for the confusion.

When trying to compute a generalized_lambert_w solution for ...

98*t + 1080*%e^(-t/10) - 1180

I need to pass numer or use a float value for z to get a float solution. For example ...

590/49 + 10*generalized_lambert_w(-1, (-54/49)*exp(-59/49));

doesn't work, but either ...

590/49 + 10*generalized_lambert_w(-1, float((-54/49)*exp(-59/49)));

or ...

590/49 + 10*generalized_lambert_w(-1, (-54/49)*exp(-59/49)),numer;

do work to find a float solution for Wm(z) for my example function.

Perhaps a note can be added to the user documentation describing how to properly manage this use case.

Maxima-version: "5.47.0"
Maxima build date: "2023-06-19 09:51:41"
Host type: "x86_64-unknown-linux-gnu"
Lisp implementation type: "SBCL"
Lisp implementation version: "2.3.5"
User dir: "/home/chris/src/maxima"
Temp dir: "/home/chris/src/maxima"
Object dir: "/home/chris/.maxima/binary/5_47_0/sbcl/2_3_5"
Frontend: false

[Raymond Toy]

This works for me:

generalized_lambert_w(-1,-((54*%e^-(59/49))/49)), numer;

But I think

float(generalized_lambert_w(-1,-((54*%e^-(59/49))/49)));

but it doesn't. Probably because the first arg is -1.0, and not -1. I suspect we could modify the simplifier to treat -1.0 (or any other float that is equal to an integer) as -1.

[Stavros Macrakis]

Not sure I understand the problem.
Maxima always preserves exact symbolic expressions.
It only calculates floating-point approximations for floating-point arguments or when simplifying with the numer flag set.
This is not specific to the Lambert function:

sin(1) => sin(1)
sin(1.0) => 0.84...
block([numer:true],sin(1)] => 0.84

So I'm not sure what the problem is with Lambert.

[Raymond Toy]

What's happening is that float(generalized_lambert_w(-1,x)) becomes generalized_lambert_w(-1.0, float(x)) and the simplifier for generalized_lambert_w checks for the fixnum -1 so -1.0 is wrong. I think the fix should be straightforward.

[Chris Gorman]

Hi Raymond and Stavros,

I did not know that maxima required the numer flag to calculate my
equation. I naively assumed that running
float(generalized_lambert_w(-1,x)) would produce a float output as it
does in other cases.

I believed that the response to this bug report would be to modify the
documentation to confirm the need of numer to calculate a float
representation of the generalized_lambert_w. Since logging the bug,
there has been some suggestion that it would be possible to have
float(generalized_lambert_w(-1,x)) work as I initially thought it
should. If it is difficult to implement an evaluation of
geteralized_lambert_w(-1.0, float(x)) with -1.0 being converted to -1
to satisfy the check in the function, then a note in the docs would be
nice.

Best regards,

Chris

On Tue, Jul 25, 2023 at 10:20 AM Raymond Toy rtoy@users.sourceforge.net wrote:

What's happening is that float(generalized_lambert_w(-1,x)) becomes generalized_lambert_w(-1.0, float(x)) and the simplifier for generalized_lambert_w checks for the fixnum -1 so -1.0 is wrong. I think the fix should be straightforward.

---

[bugs:#4156] generalized_lambert_w won't provide float solution

Status: open
Group: None
Created: Thu Jul 13, 2023 12:25 AM UTC by Chris Gorman
Last Updated: Thu Jul 13, 2023 02:22 PM UTC
Owner: David Billinghurst

When trying to compute a generalized_lambert_w solution for

98t + 1080%e^(-t/10) - 1180

I need to

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/4156/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Stavros Macrakis]

Chris, no, you shouldn't have to use numer. I think Ray is fixing this problem.
Strictly speaking, I suppose generalized_lambert_w(<float>, ...) is wrong in some sense, since the first argument must be an integer, but it seems OK to accept a float which is an exact integer.</float>

[Raymond Toy]

Yeah, this is just the way float works. It floats all the args and then calls the function again. Short of making float smarter to handle this function in a special way, I'm making generalized_lambert_w allow float/bfloat values that are integers to be treated as if they were integers.

[Chris Gorman]

Hi Raymond,

Great! Thanks.

Chris

On Tue, Jul 25, 2023 at 5:35 PM Raymond Toy rtoy@users.sourceforge.net wrote:

Yeah, this is just the way float works. It floats all the args and then calls the function again. Short of making float smarter to handle this function in a special way, I'm making generalized_lambert_w allow float/bfloat values that are integers to be treated as if they were integers.

---

[bugs:#4156] generalized_lambert_w won't provide float solution

Status: open
Group: None
Created: Thu Jul 13, 2023 12:25 AM UTC by Chris Gorman
Last Updated: Tue Jul 25, 2023 05:42 PM UTC
Owner: David Billinghurst

When trying to compute a generalized_lambert_w solution for

98t + 1080%e^(-t/10) - 1180

I need to

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/4156/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Raymond Toy]

Fixed in commit [c293301]

Basically test if the k arg is numerically equal to an integer and use the integer value instead of the float value.