Menu
▾
▴
1 Attachments
#4084 Error in [lin]solve with orderless called before
closed
nobody
5
2023-03-14
2023-01-23
No
'solve' fails with a linear equation for x of a form ax = b (a and b are specific constant expressions) with GCL Maxima if a specific orderless was called before. See the file attached and the output below:
$ maxima --batch="maxima-solve-fail.mac"
Maxima 5.46.0 https://maxima.sourceforge.io
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) batch("maxima-solve-fail.mac")
read and interpret /home/andsokol/hbar/fourier-cas/maxima-solve-fail.mac
(%i2) orderless(w1,w2,W1,W2,k1,k2,g,f1,f2,K)
(%i3) eq:(-%i)*W1*B10 = K*((%i*g*f1^3)/((%i*w1-%i*W1+k1)*((-%i)*w1+%i*W1+k1)
*((-w1)*w2+(w1+w2)*W1
-W1^2
+(%i*w2
-%i*W1)
*k1
+(%i*w1
-%i*W1+k1)
*k2))
-(%i*g*f1*f2^2)
/((%i*w1-%i*W1+k1)*(%i*w2-%i*W2+k2)
*((-w1)*w2+(w1+w2)*W2-W2^2
+((-%i)*w2+%i*W2)*k1
+((-%i)*w1+%i*W2+k1)
*k2))
+(%i*g^3*f1*f2^2)
/(((-w1)*w2+(w1+w2)*W1-W1^2+(%i*w2-%i*W1)*k1
+(%i*w1-%i*W1+k1)*k2)
*((-w1)*w2+(w1+w2)*W2-W2^2+(%i*w2-%i*W2)*k1
+(%i*w1-%i*W2+k1)*k2)
*((-w1)*w2+(w1+w2)*W2-W2^2+((-%i)*w2+%i*W2)*k1
+((-%i)*w1+%i*W2+k1)*k2)))
+(%i*g
*(((-w1)*w2^2+w2^2*W1+(2*w1*w2-2*w2*W1)*W2
+((-w1)+W1)*W2^2
+(%i*w2^2-2*%i*w2*W2+%i*W2^2)*k1
+((-w1)+W1+%i*k1)*k2^2)
*f1
+f1*f2^2*K))
/((-w1^2)*w2^2+2*w1*w2^2*W1+(-w2^2)*W1^2
+(2*w1^2*w2-4*w1*w2*W1+2*w2*W1^2)*W2
+((-w1^2)+2*w1*W1-W1^2)*W2^2
+(2*%i*w1*w2^2-2*%i*w2^2*W1
+((-4)*%i*w1*w2+4*%i*w2*W1)
*W2
+(2*%i*w1-2*%i*W1)*W2^2)
*k1+(w2^2-2*w2*W2+W2^2)*k1^2
+((-w1^2)+2*w1*W1-W1^2
+(2*%i*w1-2*%i*W1)*k1+k1^2)
*k2^2)
(%i4) solve(eq,B10)
PQUOTIENT: Quotient by a polynomial of higher degree (case 1)
-- an error. To debug this try: debugmode(true);
Same result is obtained with linsolve([eq], [B10]). Also adding - %i*w2*B10-k2*B10 to the rhs yields 'case 2a' in the same PQUOTINENT message.
Other people tested this with SBCL and CCL and were not able to reproduce this bug (see https://sourceforge.net/p/maxima/mailman/maxima-discuss/thread/CADB8Zm5JGT%2B8rqLKkrbt4W9DKor9jv5FXB3wK9-Bgn0MsFeVig%40mail.gmail.com/#msg37766742 and https://sourceforge.net/p/maxima/mailman/maxima-discuss/thread/CADB8Zm5JGT%2B8rqLKkrbt4W9DKor9jv5FXB3wK9-Bgn0MsFeVig%40mail.gmail.com/#msg37766742 ).
Note also that solve is painfully slow in CCL (16 sec according to other people on the thread), and in GCL without orderless (11-20 sec) while linsolve takes about 1 sec on GCL with such a simple equation on my Core i7-5600U CPU @ 2.60GHz.
The bug might be related to https://sourceforge.net/p/maxima/bugs/3273/
and the respective discussion https://maxima-discuss.narkive.com/yE8zdESX/quotient-by-a-polynomial-of-higher-degree.
I also tried to_poly_solve and it gives the same error:
(%o5) to_poly_solve(eq, B10);
(%i5) %solve(eq,B10)
PQUOTIENT: Quotient by a polynomial of higher degree (case 1)
I have found that ratsimp(eq) fails with a similar (albeit the "case 2b") error.
Andrii, some details aren't clear. Sorry for the bother.
(1) Did you install Maxima from an rpm, or was it only GCL which you installed from an rpm (and you built Maxima from source code)?
(2) Do I understand correctly that with Clozure CL, the calculation (including
orderless) completes without error?Thanks for any information.
(1) I did not built Maxima myself. I think I installed Maxima from maxima-exec-gcl-5.46.0-1.x86_64.rpm and maxima-5.46.0-1.x86_64.rpm from https://sourceforge.net/projects/maxima/files/Maxima-Linux/5.46.0-Linux/
(2) Personally I have not tested in with Clozure CL, but it was mentioned in the mailing list that it works with orderless (see the Barton Willis mail in the thread https://sourceforge.net/p/maxima/mailman/maxima-discuss/thread/CAAsY_sToe27Uz_7TcFfT%2BbJhAPANDOC%3DxD2dwLf%3DE_0sEDADPw%40mail.gmail.com/#msg37766880) .
The bug is also present in the CoCalc service that uses SAGE that uses Maxima built with ECL . You can check and play with it in my publicly available notebook https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe
Andrii, I tried the equation in the problem statement with current Maxima from Git, and also Maxima 5.46.0, in each case with SBCL, Clisp, GCL 2.6.14, and ECL 21.2.1, all on Linux x86_64.
Maxima 5.46.0 with GCL or ECL fails on the equation, while SBCL and Clisp do not run into an error (I wasn't able to verify the solution is correct).
Current Maxima from Git does not run into an error with SBCL, Clisp, GCL, or ECL.
I don't know why only GCL and ECL run into an error, but anyway it appears the error has gone away between 5.46.0 and the current version (many commits later).
By the way I am working with the most recent GCL release, 2.6.14. Many bugs in GCL have been fixed recently. GCL 2.6.12 is no longer supported by Maxima.
Robert, thanks for an update!
There was a discussion with Richard concerning this bug, and it might be that GCL (as well as its derivative ECL) is not able to properly handle long variable names that include capital letters https://sourceforge.net/p/maxima/mailman/message/37768131/. The reasoning behind that is that this bug can be fixed by changing W1 to wu1 etc (see https://sourceforge.net/p/maxima/mailman/message/37768148/ by Michel).
So it is good that the error has gone away, but could that be merely a result of an accident? For example, maybe we have other aliasing scheme in the new GCL and/or the new Maxima, and it just happens to work in this particular example?
Last edit: Andrii Sokolov 2023-03-14
git bisectshows that commit 9e0ed65 fixes this bug for ECL 21.2.1. Commit message says that commit was to fix a GCD bug. It makes sense that a GCD bug fix would also fix this bug, but I don't know why this bug only show up in GCL or ECL.Commit 9e0ed65 also makes the error go away for GCL 2.6.12.
I'm going to close this bug report, as it appears that there is a specific commit which fixes the bug for the Lisp implementations which showed it. If the bug reappears for more recent versions, or for other Lisp implementations, we will resume the discussion; I think it would be more useful to open a new bug report instead of reopening this one, for what it's worth.