#4208 Error with complex numbers - example with trigreduce

[Dr. David Kirkby]

I'm a first-year Open University student studying for a Mathematics degree. We have to use Maxima but are told to use an older version because of a bug with complex numbers in recent releases. I believe that the Open University are recommending we use version 5.38.1 of Maxima. I can see the bug with Maxima 5.47.0

I'm trying to attach multiple files, but it's not clear from the Sourceforge interface if more than one is being attached. If not, I will attach other files later. The bug is demonstrated by activity 65 of the Computer Algebra Guide. I have, or at least will soon, attach a few pages from that, which show what should be done, and the answers in the back of the book.

I have verified the results in the Mathematica. ** This is a regression, as Maxima used to provide the correct results, but recent(ish) releases are not. **

These Maxima commands demonstrate the bug.

c:3*(cos(5*%pi/13)+%i*sin(5*%pi/13));
d:4*(cos(7*%pi/13)+%i*sin(7*%pi/13));
trigreduce(carg(c*d));

That gives a result of 25 Pi/13, but the correct result is 12 Pi/13. Mathematica does not show 12 Pi/13, but produces a huge expression I'm not going to bother trying to write. But converting Mathematic's symbolic expression to a numerical value, computed with 60 digits of precision, gives the same as 12 Pi/13 computed to 60 digits.

c = 3 (Cos[5 Pi/13] + I Sin[5 Pi/13])
d = 4 (Cos[7 Pi/13] + I Sin[7 Pi/13])
N[TrigReduce[Arg[c d]], 60]
2.89993168023673222011936312302723343156661790711548229628456
N[12 Pi/13, 60]
2.89993168023673222011936312302723343156661790711548229628456

This Maxima command also gives the wrong result.

trigreduce(carg(c/d));

That gives a result of 11 Pi/13, but the correct result is 24 Pi/13.

[Dr. David Kirkby]

Adding a section from the Open University Computer Algebra guide for the module I'm studying.

[Dr. David Kirkby]

Maxima worksheet demonstrating the bug.

[Dr. David Kirkby]

Results computed with Mathematica.

[Dr. David Kirkby]

I should have added, the result from the earlier version of Maxima for

trigreduce(carg(c/d))

is 24 Pi/13.

Is you subtract 2 Pi it is -2 Pi/13, which is what Mathematica gives, with

N[TrigReduce[Arg[c/d]], 60]
-0.483321946706122036686560520504538905261102984519247049380761

N[-2 Pi/13, 60]
-0.483321946706122036686560520504538905261102984519247049380761

[Raymond Toy]

I think it's a problem with how trigreduce handles atan(sin(x)/cos(x)) in combination with triginverses:true, which is the default.

trigreduce will convert sin(7*%pi/13)/cos(7*%pi/13) to tan(7*%pi/13) as expected. Then atan(tan(7*%pi/13)) is 7*%pi/13 with triginverses:true but -6*%pi/13 with triginverses:false.

I didn't look, but maybe trigreduce sets triginverses:true, because trigreduce(cargs(c*d)) produces the wrong answer even if I set triginverses:false.

[Dr. David Kirkby]

Something has probably changed in trigreduce then, as it used to work properly.

I did not add any labels to this bug report - I did not see the option. But perhaps someone with more knowledge of me can add appropriate labels.

It's impressive how nice the result is from earlier versions of Maxima compare to a current version of Mathematica, which produces a huge expression, rather than a simple irrational number. But Maxima producing the wrong answer is clearly not desirable.

[Robert Dodier]

Thanks for the hint. git bisect shows that the offending commit is the following. Incidentally this commit is between versions 5.41 and 5.42.

commit 30ed02e0028a1b2bec5c2d144119417913328fe2 (HEAD, refs/bisect/bad)
Author: Robert Dodier <robert_dodier@users.sourceforge.net>
Date:   Mon Mar 5 11:20:26 2018 -0800

    In SP1ATRIG, correct argument for ZL-GET.
    Fixes SF bug #3399: "trigreduce gives malformed property list error"

diff --git a/src/trgred.lisp b/src/trgred.lisp
index a7fe434..3ffb771 100644
--- a/src/trgred.lisp
+++ b/src/trgred.lisp
@@ -620,7 +620,7 @@
 (defun sp1atrig (fn exp)
   (cond ((atom exp)
         (sp1atrig2 fn exp))

-       ((eq fn (zl-get (cadr exp) '$inverse))
+       ((eq fn (zl-get (caar exp) '$inverse))
         (sp1 (cadr exp)))
        (t (sp1atrig2 fn exp))))

Glancing at this, I don't see how that comes into play in the example you showed in the problem statement above, however, git bisect shows that this is the commit where the result changed from 12*%pi/13 to 25*%pi/13.

I wonder if there is a simpler example which shows the same incorrect behavior.

[Raymond Toy]

That's a good hint. I think that means in the old version, we probably weren't calling sp1 and falling through to the default case of calling sp1atrig2.

Maybe the solution here is to change the condition to also check for the value of triginverses to be true before calling sp1?

[Dr. David Kirkby]

One of the staff tutors at the Open University contacted me with a simpler example. I'll just copy/paste what he wrote:

"If you would like to see an easier example of the carg bug then it happens for any angle larger than pi/2. For example trigreduce(carg(cos(3*%pi/5)+%i * sin(3*%pi/5))) will give the incorrect answer."

[Dr. David Kirkby]

I've asked a few people at the Open University if they know of a simpler example. None do, but one of the senior academics is going to try to look into whether she can provide a simpler example. I don't have the mathematical ability to do so myself, but I knew enough of Mathematica to satisfy myself they were correct in identifying this as a bug.

[Robert Dodier]

Fixed by commit [ 723d702 ]. Closing this report.