rtoy / maxima

A Clone of Maxima's repo
Other
0 stars 0 forks source link

tanh(200.0-200.0*%i) is incorrect #3652

Open rtoy opened 4 months ago

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:04:46 Created by rtoy on 2024-05-07 15:28:42 Original: https://sourceforge.net/p/maxima/bugs/4301


Maxima says tanh(200.0-200.0*%i) is 1.0 - 1.0*%i. That's not right. Compare that with the result of tanh(200b0-200b0*%i)=3.259b-174*%i+1.0b0.

Also rectform(tanh(200-200*%i)) is sinh(400)/(cosh(400)+cos(400))-(%i*sin(400))/(cosh(400)+cos(400)). That evaluates to 3.259e-174*%i + 1.0, which matches the bigfloat value.

Have not looked into what's causing the problem.

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:04:47 Created by willisbl on 2024-05-07 15:56:23 Original: https://sourceforge.net/p/maxima/bugs/4301/#c583


I haven't looked to see how Maxima numerically evaluates tanh, but this is what I get with SBCL & Clozure

This is SBCL 2.2.2, an implementation of ANSI Common Lisp.

Clozure Common Lisp Version 1.12.2 (v1.12.2) WindowsX8664

? (cl::tanh #C(200.0 200.0))

C(1.0 -0.0)

--Barton


From: Raymond Toy via Maxima-bugs maxima-bugs@lists.sourceforge.net Sent: Tuesday, May 7, 2024 10:28 To: maxima-bugs@lists.sourceforge.net maxima-bugs@lists.sourceforge.net Cc: Raymond Toy rtoy@users.sourceforge.net Subject: [Maxima-bugs] [maxima:bugs] #4301 tanh(200.0-200.0*%i) is incorrect

Caution: Non-NU Email


[bugs:#4301]https://sourceforge.net/p/maxima/bugs/4301/ tanh(200.0-200.0*%i) is incorrect

Status: open Group: None Labels: tanh Created: Tue May 07, 2024 03:28 PM UTC by Raymond Toy Last Updated: Tue May 07, 2024 03:28 PM UTC Owner: nobody

Maxima says tanh(200.0-200.0%i) is 1.0 - 1.0%i. That's not right. Compare that with the result of tanh(200b0-200b0%i)=3.259b-174%i+1.0b0.

Also rectform(tanh(200-200%i)) is sinh(400)/(cosh(400)+cos(400))-(%isin(400))/(cosh(400)+cos(400)). That evaluates to 3.259e-174*%i + 1.0, which matches the bigfloat value.

Have not looked into what's causing the problem.


Sent from sourceforge.net because maxima-bugs@lists.sourceforge.net is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

Attachments:

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:04:51 Created by willisbl on 2024-05-07 16:24:29 Original: https://sourceforge.net/p/maxima/bugs/4301/#c583/0303


Oh, I missed the negation on the imaginary part:

SBCL

Clozure

? (cl::tanh #C(200.0 -200.0))

C(1.0 0.0)

--Barton


From: Barton Willis via Maxima-bugs maxima-bugs@lists.sourceforge.net Sent: Tuesday, May 7, 2024 10:43 To: maxima-bugs@lists.sourceforge.net maxima-bugs@lists.sourceforge.net; Ticket #4301: tanh(200.0-200.0%i) is incorrect 4301@bugs.maxima.p.re.sourceforge.net Cc: Raymond Toy rtoy@users.sourceforge.net Subject: Re: [Maxima-bugs] [maxima:bugs] #4301 tanh(200.0-200.0%i) is incorrect

Caution: Non-NU Email

I haven't looked to see how Maxima numerically evaluates tanh, but this is what I get with SBCL & Clozure

This is SBCL 2.2.2, an implementation of ANSI Common Lisp.

Clozure Common Lisp Version 1.12.2 (v1.12.2) WindowsX8664

? (cl::tanh #C(200.0 200.0))

C(1.0 -0.0)

--Barton


From: Raymond Toy via Maxima-bugs maxima-bugs@lists.sourceforge.net Sent: Tuesday, May 7, 2024 10:28 To: maxima-bugs@lists.sourceforge.net maxima-bugs@lists.sourceforge.net Cc: Raymond Toy rtoy@users.sourceforge.net Subject: [Maxima-bugs] [maxima:bugs] #4301 tanh(200.0-200.0*%i) is incorrect

Caution: Non-NU Email


[bugs:#4301]https://sourceforge.net/p/maxima/bugs/4301/ tanh(200.0-200.0*%i) is incorrect

Status: open Group: None Labels: tanh Created: Tue May 07, 2024 03:28 PM UTC by Raymond Toy Last Updated: Tue May 07, 2024 03:28 PM UTC Owner: nobody

Maxima says tanh(200.0-200.0%i) is 1.0 - 1.0%i. That's not right. Compare that with the result of tanh(200b0-200b0%i)=3.259b-174%i+1.0b0.

Also rectform(tanh(200-200%i)) is sinh(400)/(cosh(400)+cos(400))-(%isin(400))/(cosh(400)+cos(400)). That evaluates to 3.259e-174*%i + 1.0, which matches the bigfloat value.

Have not looked into what's causing the problem.


Sent from sourceforge.net because maxima-bugs@lists.sourceforge.net is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

Attachments:

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:04:55 Created by rtoy on 2024-05-07 23:02:00 Original: https://sourceforge.net/p/maxima/bugs/4301/#c583/0303/7621


This is really bizarre. I thought it was a problem with cmucl ,which is what I was using when I found this. But for me ccl64 says (cl:atanh #c(200.0 -200.0)) is #C(1.0 3.259309773672603E-174) which is correct. But I get the incorrect answer with sbcl.

So, this looks like a bug in cmucl and sbcl, not in maxima?

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:04:58 Created by rtoy on 2024-05-07 23:05:08 Original: https://sourceforge.net/p/maxima/bugs/4301/#c583/0303/7621/4eae


Yep. It's a bug in cmucl and presumably sbcl. For large enough values, cmucl returns #c(1d0 -1d0). Cmucl gets the right answer for (tanh #c(100d0 -100d0)): #C(1.0d0 2.417106192846055d-87).

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:05:02 Created by rtoy on 2024-05-08 15:27:27 Original: https://sourceforge.net/p/maxima/bugs/4301/#be89


rtoy commented 4 months ago

Imported from SourceForge on 2024-07-08 11:05:05 Created by rtoy on 2024-05-08 15:27:27 Original: https://sourceforge.net/p/maxima/bugs/4301/#abd9


This is not a bug in Maxima. For complex floats, Maxima calls cl:tanh to evaluate it. The error comes from Lisp. ccl, ecl, gcl, and clisp return the correct answer. However, ecl and gcl both return 1.0. I was expecting a complex result, but I think that's still ok.