From: Andrii S. <and...@gm...> - 2023-01-22 17:36:02
|
Dear all, Recently I was not able to use 'solve' for an elementary linear equation--- if 'orderless' was called before. The commands are invoked are the following (sorry for a lengthy input): orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ 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)$ solve(eq, B10); which spits out: PQUOTIENT: Quotient by a polynomial of higher degree (case 1) Also if the rhs includes '- %i*w2*B10-k2*B10' additionaly, it diagnoses 'case 2a' in the same PQUOTINENT message. In both cases 'solve' provides an answer if 'orderless' was not called. I played a bit removing different parts of the equation and it was unclear for me what causes an error. Could that be a bug? Probably related to https://sourceforge.net/p/maxima/bugs/3273/ and the discussion https://maxima-discuss.narkive.com/yE8zdESX/quotient-by-a-polynomial-of-higher-degree I use Maxima 5.46.0 with GCL 2.6.12 from the RHEL 8 repo. Regards, Andrii |
From: Barton W. <wi...@un...> - 2023-01-22 18:41:09
|
This bug (and yes, it’s a bug), might be compiler dependent. When I try with a current build using Clozure CL, the calculation at least finishes. I didn’t check that it’s correct. This is what I got (%i3) xxx : solve(eq,B10)$ (%i4) time(%o3); (%o4) [16.578125] (%i5) reveal(xxx,7); (%o5) [B10=-(Sum(2)*K+Sum(21)*g*f1)/(Sum(15)*Expt+Sum(17)*Expt+Sum(17)*Expt+Sum(19)*k2+Sum(5)*Expt+Sum(6)*Expt+Sum(9)*Expt+ Sum(10)*Expt+Sum(11)*Expt+Sum(12)*Expt+Sum(11)*k1+Sum(7)*Expt+Sum(7)*Expt+Sum(7)*Expt+Sum(7)*Expt+Sum(7)*W2+%i*Expt*Expt*Expt+Sum(2)*Expt +Sum(2)*Expt+Sum(2)*Expt+Sum(2)*Expt+Sum(2)*Expt+%i*Expt*Expt*W1)] (%i6) build_info(); (%o6) build_info(version="5.46post",timestamp="2023-01-07 03:40:57",host="unknown",lisp_name="Clozure Common Lisp",lisp_version="Version 1.12.1 (v1.12.1) WindowsX8664 Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows ________________________________ From: Andrii Sokolov <and...@gm...> Sent: Sunday, January 22, 2023 11:35:52 AM To: max...@li... <max...@li...> Subject: [Maxima-discuss] Error in solve with orderless called before Non-NU Email Dear all, Recently I was not able to use 'solve' for an elementary linear equation--- if 'orderless' was called before. The commands are invoked are the following (sorry for a lengthy input): orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ 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)$ solve(eq, B10); which spits out: PQUOTIENT: Quotient by a polynomial of higher degree (case 1) Also if the rhs includes '- %i*w2*B10-k2*B10' additionaly, it diagnoses 'case 2a' in the same PQUOTINENT message. In both cases 'solve' provides an answer if 'orderless' was not called. I played a bit removing different parts of the equation and it was unclear for me what causes an error. Could that be a bug? Probably related to https://urldefense.com/v3/__https://sourceforge.net/p/maxima/bugs/3273/__;!!PvXuogZ4sRB2p-tU!B_nFKs4dFUmOenY-OM_ATsw57PXmcz122x3UBx_lAOzTYMwwO4LLHHidd0DXAWOdDEuyDOkgRIAAQV_P$ and the discussion https://urldefense.com/v3/__https://maxima-discuss.narkive.com/yE8zdESX/quotient-by-a-polynomial-of-higher-degree__;!!PvXuogZ4sRB2p-tU!B_nFKs4dFUmOenY-OM_ATsw57PXmcz122x3UBx_lAOzTYMwwO4LLHHidd0DXAWOdDEuyDOkgRG9fxOFQ$ I use Maxima 5.46.0 with GCL 2.6.12 from the RHEL 8 repo. Regards, Andrii _______________________________________________ Maxima-discuss mailing list Max...@li... https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!B_nFKs4dFUmOenY-OM_ATsw57PXmcz122x3UBx_lAOzTYMwwO4LLHHidd0DXAWOdDEuyDOkgRLTq90HT$ |
From: Richard F. <fa...@gm...> - 2023-01-22 18:58:39
|
. I found no error in maxima 5.45.1 using wxmaxima front end (which, however, refused to display the result in 2D because of its length.) Could it be that some of those items in orderless() had previously been set to values? Note also that solving for B10 is particularly trivial since B10 occurs only once, as given. This kind of error usually depends on some hidden dependency, like a sqrt(b) in the expression. Since sqrt(b)^2-b is not obviously zero if sqrt(b) is given a different and unrelated symbolic name in the rational function system, there is an opportunity for missing common factors and a cancellation. Thanks for reporting this. RJF On Sun, Jan 22, 2023 at 9:36 AM Andrii Sokolov <and...@gm...> wrote: > Dear all, > > Recently I was not able to use 'solve' for an elementary linear equation--- > if 'orderless' was called before. The commands are invoked are the > following > (sorry for a lengthy input): > > orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ > > 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)$ > > solve(eq, B10); > > which spits out: > > PQUOTIENT: Quotient by a polynomial of higher degree (case 1) > > Also if the rhs includes '- %i*w2*B10-k2*B10' additionaly, it diagnoses > 'case 2a' in the same PQUOTINENT message. In both cases 'solve' provides > an answer if 'orderless' was not called. > > I played a bit removing different parts of the equation and it was unclear > for me what causes an error. > > Could that be a bug? Probably related to > https://sourceforge.net/p/maxima/bugs/3273/ > and the discussion > https://maxima-discuss.narkive.com/yE8zdESX/quotient-by-a-polynomial-of-higher-degree > > I use Maxima 5.46.0 with GCL 2.6.12 from the RHEL 8 repo. > > Regards, > Andrii > > > > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |
From: Andrii S. <and...@gm...> - 2023-01-23 08:26:40
|
When I tried to test this behaviour, I used maxima --batch="solve-fail.mac" with "solve-fail.mac" containing the reported input. I also tried starting maxima and pasting the input manually--same result of course. So I think there are no values set for the 'orderless' variables. And yes, the fact that the equation is trivial makes me mad. I'll probably code smth like 'linsolve1' specially for my case (approximate iterative solution of a set of nonlinear polynomial equations), where I need many thousands of calls to [lin]solve. The fact that 'solve' is so slow (16 sec as reported by Barton Willis in CCL, 22 sec for me) is also very annoying. Actually 'linsolve' is much faster, takes about 1 sec. Why is it so? The manual for 'solve' says "solve [...] solves a system of simultaneous (linear or non-linear) polynomial equations by calling linsolve or algsys [...]". Thanks all for trying this out and for suggestions. Andrii Sokolov On Sun, 2023-01-22 at 10:58 -0800, Richard Fateman wrote: > . I found no error in maxima 5.45.1 using wxmaxima front end (which, > however, refused to display the result in 2D because of its length.) > > Could it be that some of those items in orderless() had previously been set to values? Note also > that solving for B10 > is particularly trivial since B10 occurs only once, as given. This kind of error usually depends > on some hidden > dependency, like a sqrt(b) in the expression. Since sqrt(b)^2-b is not obviously zero if sqrt(b) > is given a different and > unrelated symbolic name in the rational function system, there is an opportunity for missing > common factors and > a cancellation. > Thanks for reporting this. > RJF > > On Sun, Jan 22, 2023 at 9:36 AM Andrii Sokolov <and...@gm...> wrote: > > Dear all, > > > > Recently I was not able to use 'solve' for an elementary linear equation--- > > if 'orderless' was called before. The commands are invoked are the following > > (sorry for a lengthy input): > > > > orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ > > > > eq : -%i*W1*B10 = K * ((%i*g*f1^3)/((%i*w1-%i*W1+k1)*((-%i*w1)+%i*W1+k1) > > [...] > > +((-w1^2)+2*w1*W1-W1^2+(2*%i*w1-2*%i*W1)*k1 > > +k1^2) > > *k2^2)$ > > > > solve(eq, B10); > > > > which spits out: > > > > PQUOTIENT: Quotient by a polynomial of higher degree (case 1) > > > > Also if the rhs includes '- %i*w2*B10-k2*B10' additionaly, it diagnoses > > 'case 2a' in the same PQUOTINENT message. In both cases 'solve' provides > > an answer if 'orderless' was not called. > > > > I played a bit removing different parts of the equation and it was unclear > > for me what causes an error. > > > > Could that be a bug? Probably related to https://sourceforge.net/p/maxima/bugs/3273/ > > and the discussion > > https://maxima-discuss.narkive.com/yE8zdESX/quotient-by-a-polynomial-of-higher-degree > > > > I use Maxima 5.46.0 with GCL 2.6.12 from the RHEL 8 repo. > > > > Regards, > > Andrii > > > > > > > > _______________________________________________ > > Maxima-discuss mailing list > > Max...@li... > > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
From: Robert D. <rob...@gm...> - 2023-01-23 02:16:25
|
On Sun, Jan 22, 2023 at 9:40 AM Andrii Sokolov <and...@gm...> wrote: > Recently I was not able to use 'solve' for an elementary linear equation--- > if 'orderless' was called before. The commands are invoked are the following > (sorry for a lengthy input): > > orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ > > eq : -%i*W1*B10 = K * ((%i*g*f1^3)/((%i*w1-%i*W1+k1)*((-%i*w1)+%i*W1+k1) [...] > *k2^2)$ > > solve(eq, B10); > > which spits out: > > PQUOTIENT: Quotient by a polynomial of higher degree (case 1) Hmm, I can't reproduce this error. I tried it with Maxima 5.46.0 and current Git version (post-5.46) with SBCL on Linux, and tried it with orderless and without, and in all cases, solve(eq, B10) concludes without error, and the result appears to be correct -- I see that rhs(eq) is free of B10, so the result should be just rhs(eq)/(-%i*W1), which I tested with ratsimp(rhs(eq)/(-%i*W1) - rhs(%o3[1])) where %o3 is the output from solve, and got 0 as expected. Not sure what's going on here. Can you create a bug report? Maybe someone can try it with GCL. best, Robert |
From: Andrii S. <and...@gm...> - 2023-01-23 09:30:26
|
Thanks for feedback and some testing. Created a bug report https://sourceforge.net/p/maxima/bugs/4084/ Andrii On Sun, 2023-01-22 at 18:16 -0800, Robert Dodier wrote: > On Sun, Jan 22, 2023 at 9:40 AM Andrii Sokolov <and...@gm...> wrote: > > > Recently I was not able to use 'solve' for an elementary linear equation--- > > if 'orderless' was called before. The commands are invoked are the following > > (sorry for a lengthy input): > > > > orderless(w1, w2, W1, W2, k1, k2, g, f1, f2, K)$ > > > > eq : -%i*W1*B10 = K * ((%i*g*f1^3)/((%i*w1-%i*W1+k1)*((-%i*w1)+%i*W1+k1) > [...] > > *k2^2)$ > > > > solve(eq, B10); > > > > which spits out: > > > > PQUOTIENT: Quotient by a polynomial of higher degree (case 1) > > Hmm, I can't reproduce this error. I tried it with Maxima 5.46.0 and > current Git version (post-5.46) with SBCL on Linux, and tried it with > orderless and without, and in all cases, solve(eq, B10) concludes > without error, and the result appears to be correct -- I see that > rhs(eq) is free of B10, so the result should be just rhs(eq)/(-%i*W1), > which I tested with ratsimp(rhs(eq)/(-%i*W1) - rhs(%o3[1])) where %o3 > is the output from solve, and got 0 as expected. > > Not sure what's going on here. Can you create a bug report? Maybe > someone can try it with GCL. > > best, > > Robert |
From: Richard F. <fa...@gm...> - 2023-01-23 15:24:52
|
It is difficult for us to debug a problem that we can't reproduce! On an SBCL lisp on my computer, I tried once.. the time for solve is 5.9 sec with orderless, and 3.9 without orderless. I suggest that you try this: eq2: rhs(eq)-lhs(eq)$ ratsimp(eq2)$ factor(eq2)$ rat(eq2,B10)$ See if you get the pquotient message for these programs. Maybe narrow the problem with this: :lisp (trace ratf pfactor solve1a) solve(eq2,B10)$ On Mon, Jan 23, 2023 at 1:30 AM Andrii Sokolov <and...@gm...> wrote: > Thanks for feedback and some testing. > > Created a bug report https://sourceforge.net/p/maxima/bugs/4084/ > > > |
From: Andrii S. <and...@gm...> - 2023-01-24 20:12:08
|
Both ratsimp(eq2) and factor(eq2) spit out the PQUOTINENT error. However, rat(eq2,B10) provides a result. Regarding the possibility to reproduce this bug, I have found an online web interface to Maxima that behaves just like the Maxima on my machine http://maxima.cesga.es/index.php?c=56av4icbo5uzn3routiuo&n=7 <http://maxima.cesga.es/index.php?c=56av4icbo5uzn3routiuo&n=7> The site prints "Programming error detected. Check your input.» for my input with orderless, but I guess it gives it for any maxima error. Unfortunately they block calls to build_info() but, well, my first guess was that it’s GCL that is used. And more than that. Actually there is this very bug in SAGE, at least in the CoCalc service that uses it. You can find my worksheet demonstrating that bug and play with it by the link https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe <https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe> And… wait a minute—that uses ECL! And well, I know it is ECL which is also used in the Android port of Maxima. Unfortunately, I do not have an Android device to check that bug. Andrii > 23 січ. 2023 р. о 17:24 Richard Fateman <fa...@gm...> написав(ла): > > It is difficult for us to debug a problem that we can't reproduce! > On an SBCL lisp on my computer, I tried once.. > the time for solve is 5.9 sec with orderless, and 3.9 without orderless. > > I suggest that you try this: > eq2: rhs(eq)-lhs(eq)$ > ratsimp(eq2)$ > factor(eq2)$ > rat(eq2,B10)$ > > > See if you get the pquotient message for these programs. > > Maybe narrow the problem with this: > :lisp (trace ratf pfactor solve1a) > solve(eq2,B10)$ > > On Mon, Jan 23, 2023 at 1:30 AM Andrii Sokolov <and...@gm... <mailto:and...@gm...>> wrote: > Thanks for feedback and some testing. > > Created a bug report https://sourceforge.net/p/maxima/bugs/4084/ <https://sourceforge.net/p/maxima/bugs/4084/> > > |
From: Richard F. <fa...@gm...> - 2023-01-24 20:29:19
|
It would, of course, be nice to have a much much smaller example to demonstrate this problem. Here's a guess about how it might appear in GCL and ECL both! Common lisp's standard was defined mostly by people at MIT, Stanford and CMU. They rejected my suggestion that characters should have 8 bits as in UNIX and insisted that lower-case characters should be treated as UPPER CASE. This made sense for the PDP-10 computers from DEC, where characters were packed into 36 bit words. This decision did not wear well, I think. When 8 bits is not enough! Anyway, it could be that some Common Lisps don't properly treat the upper/lower case requirements in Maxima and get confused by your use of both w1 and W1. So my suggestion, if you have the energy and a handy editor, is to change your data so that you have variables like W1 rewritten as wu1 (that is to remind you that it is w_upper_case_1).. etc. etc. And see if that works. RJF On Tue, Jan 24, 2023 at 12:11 PM Andrii Sokolov <and...@gm...> wrote: > Both ratsimp(eq2) and factor(eq2) spit out the PQUOTINENT > error. However, rat(eq2,B10) provides a result. > > Regarding the possibility to reproduce this bug, I have found an online > web interface to Maxima that behaves just like the Maxima on my machine > http://maxima.cesga.es/index.php?c=56av4icbo5uzn3routiuo&n=7 The site > prints "Programming error detected. Check your input.» for my input with > orderless, but I guess it gives it for any maxima error. Unfortunately they > block calls to build_info() but, well, my first guess was that it’s GCL > that is used. > > And more than that. Actually there is this very bug in SAGE, at least in > the CoCalc service that uses it. You can find my worksheet demonstrating > that bug and play with it by the link > https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe And… > wait a minute—that uses ECL! > > And well, I know it is ECL which is also used in the Android port of > Maxima. Unfortunately, I do not have an Android device to check that bug. > > Andrii > > > > 23 січ. 2023 р. о 17:24 Richard Fateman <fa...@gm...> написав(ла): > > It is difficult for us to debug a problem that we can't reproduce! > On an SBCL lisp on my computer, I tried once.. > the time for solve is 5.9 sec with orderless, and 3.9 without orderless. > > I suggest that you try this: > eq2: rhs(eq)-lhs(eq)$ > ratsimp(eq2)$ > factor(eq2)$ > rat(eq2,B10)$ > > > See if you get the pquotient message for these programs. > > Maybe narrow the problem with this: > :lisp (trace ratf pfactor solve1a) > solve(eq2,B10)$ > > On Mon, Jan 23, 2023 at 1:30 AM Andrii Sokolov <and...@gm...> > wrote: > >> Thanks for feedback and some testing. >> >> Created a bug report https://sourceforge.net/p/maxima/bugs/4084/ >> >> >> > |
From: Michel T. <ta...@lp...> - 2023-01-24 21:03:35
|
Hello, Richard I think you have spotted the bug. I happen to have maxima -l gcl here coming from the Ubuntu distribution. And i get the same bug as Andrei Maxima 5.43.2 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.12 ....... solve(eq, B10); PQUOTIENT: Quotient by a polynomial of higher degree (case 1) -- an error. To debug this try: debugmode(true); I have then edited the program by changing everywhere W1 by wu1 and W2 by wu2. Then the bug disappears, and gcl produces the result after a *very* long time. In fact 35 s. By comparison, the same computation with sbcl on the same machine takes 21s. So sbcl is faster thangcl but not by a very large margin. Le 24/01/2023 à 21:28, Richard Fateman a écrit : > > Common lisp's standard was defined mostly by people at MIT, Stanford > and CMU. They rejected > my suggestion that characters should have 8 bits as in UNIX and > insisted that lower-case characters > should be treated as UPPER CASE. This made sense for the PDP-10 > computers from DEC, where > characters were packed into 36 bit words. This decision did not wear > well, I think. When 8 bits is not enough! > > Anyway, it could be that some Common Lisps don't properly treat the > upper/lower case requirements > in Maxima and get confused by your use of both w1 and W1. -- Michel Talon |