You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(9) 
From: SourceForge.net <noreply@so...>  20060909 02:14:42

Bugs item #788360, was opened at 20030813 15:25 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788360&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: algsys a*b=c*d grossly incomplete Initial Comment: algsys([a*b=c*d],[a,b,c,d]) returns [[a = %R2*%R3/%R1,b = %R1,C = %R2,d = %R3]] This is missing some of the solutions where one or both of a and b is zero and one or both of c and d is zero. The complete list of these solutions is: [[a=0,b=%r1,c=0,d=%r2], [a=0,b=%r3,c=%r4,d=0], [a=%r5,b=0,c=0,d=%r6], [a=%r7,b=0,c=%r8,d=0]] The first two are subsumed by the original solution as long as b # 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788360&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 02:05:06

Bugs item #826623, was opened at 20031019 22:25 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplifer returns %i*%i Initial Comment: ((%i)^(1/2)*%i)*((%i)^(1/2)) => %i*%i Resimplifying  expand(%,0,0)  correctly returns 1. Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:40 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031019 23:55 Message: Logged In: YES user_id=588346 This may be related to the inconsistent simplification of simple expressions involving %i: Mathematically, %i^(1/4) = (%i)^(1/4), but the first simplifies to (1)^(1/8) and the second to (%i)^(1/4) . Mathematically, (1)^(1/4) = %i^(1/2) = (%i)^(1/2), but the first two simplify to 1/(1)^(1/4), while the third simplifies to sqrt(%i). There are other similar cases. This is also reminiscent of the the nonnormalization of 1/sqrt(2)  bug # 721575.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 02:04:08

Bugs item #817567, was opened at 20031003 22:44 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817567&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Polynomials Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor/poly leaves common factors Initial Comment: ff: factor(x^22,8*q^4q*q^2+1) => (16*x64*q^2+32)*(16*x+64*q^232)/256 Of course, this can be simplified with another pass of ordinary factorization: factor(ff) => (x4*q^2+2)*(x+4*q^22) A simpler example, but perhaps suspect because it uses q in the polynomial to factor: factor(xq,2*q^2+1) => (2*x2*q)/2  Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:34 Message: Logged In: YES user_id=501686 5.9.3cvs yields (%i10) ff: factor(x^22,8*q^4q*q^2+1) ; (%o10) x^22 Not sure what the right result is here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817567&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 02:01:58

Bugs item #808676, was opened at 20030918 10:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: bfloat(1+10^30) rounds wrong with fpprec:20 Initial Comment: fpprec:20$ bfloat(1+10^30)  1; > 3.388...B21 The correct answer is 0.0b0, because bfloat(1+10^30) should round to exactly 1.0b0.  Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:38 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Raymond Toy (rtoy) Date: 20041123 11:27 Message: Logged In: YES user_id=28849 I think the problem is because it converts the ratio (10^30+1)/10^30 to a bigfloat and doesn't quite round correctly. It's off by one bit. Adding 1b0+1b30 does round correctly and return 1b0 exactly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 01:55:54

Bugs item #816166, was opened at 20031001 16:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816166&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform/carg doesn't normalize exp(%i*n) (also asin, log) Initial Comment: carg(exp(%i*x)) => x (OK?) carg(exp(%i*10.0)) => 10.0 (No?) carg(exp(%i*%pi)) => %pi (OK) float(carg(exp(%i*%pi))) => 3.14 (OK) carg(exp(%i*float(%pi))) => 3.14 (?) float(carg(asin(%i*10))) => 1.57 (OK) carg(asin(%i*10)),numer => 4.71 (No!) float(rectform(log(%i*10))) => 2.30  1.57*%I (OK) rectform(log(%i*10)),numer => 2.30+4.71*%I (No!) Presumably the principal values is what is wanted. I will correct that. This is related to the fact that carg(exp(%i*x)) doesn't normalize x to (pi,pi] when x is not an explicit multiple of pi: carg(exp(%i*10)) => 10 carg(exp(%i*x)) => x but carg(exp(%i*(3*%pix))) => %pix How far should this go? I think it's pretty clear for the float/bfloat case, but how about carg(exp(%i*10))? Should that really return 104*%pi? Currently, it goes the other way around!: exp(%i*(104*%pi)) actually simplifies to exp(%i*10)....  Comment By: Barton Willis (willisbl) Date: 20050718 04:42 Message: Logged In: YES user_id=895922 How about 'nummod'? See my recent Maxima list posting and "Concrete Mathematics" by Graham, Knuth, and Patashnik, Section 3.4 (%i1) load("C:/maxima/nummod/nummod.lisp")$ (%i2) f(x) := %pi  nummod(%pix,2*%pi)$ (%i3) f(%pi); (%o3) %pi (%i4) f(0); (%o4) 0 (%i5) f(%pi); (%o5) %pi (%i6) f(%pi + 1/10^9); (%o6) 1/1000000000%pi (%i7) f(%pi  1/10^9); (%o7) %pi1/1000000000 (%i8) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050716 01:15 Message: Logged In: YES user_id=501686 Well, how about carg (exp (%i*10)) => 'mod (10, 2*%pi) ??  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816166&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 01:53:14

Bugs item #932395, was opened at 20040409 11:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932395&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve confused by ratvars Initial Comment: solve(rat(a+c,a,b,c,d),[a,b]) => [[a=%r1, b=%r1]] NO! Remove the extra variable: solve(rat(a+c,a,b,c),[a,b]) => [[a =  c, b = %r2]] OK Also works fine if you call algsys directly: algsys([rat(a+c,a,b,c,d)],[a,b]); At first I thought this had something to do with the variable *ordering* in the first case, but in fact it happens with all orderings. The problem is the number of ratvars. Note that this is *not* an artificial situation. It is common to have CREs with more ratvars than they use after arithmetic operations, e.g. rat(a+b)rat(a).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932395&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 01:51:28

Bugs item #1227953, was opened at 20050626 17:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1227953&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: uncaught exception on floating point overflow (GCL) Initial Comment: Using GCL 2.6.6/Maxima 5.9.1cvs. Usually if there is a floating point overflow, Maxima catches the GCL error and returns to the Maxima command prompt after printing an error message. E.g. in a fresh session: (%i1) 1e300*1e300; Maxima encountered a Lisp error: Error in PROGN [or a callee]: Can't print a nonnumber. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) However, sometimes the error is not caught, and instead of getting the Maxima prompt, the user gets the GCL debugger prompt. I've been able to cause this to happen a few times, but the only reproduceable example I have is the following. The example is contained in the attached file musa.mac.  begin transcript  (%i1) T: matrix ([3, 45, 6, 7, 8]); (%o1) [ 3 45 6 7 8 ] (%i2) t: matrix ([0, 3, 48, 54, 61, 69]); (%o2) [ 0 3 48 54 61 69 ] (%i3) F1(N,F):= 5/N  sum (F*exp(F*t[1,i])*T[1,i], i, 1, 5); 5 (%o3) F1(N, F) :=   sum(F exp(( F) t ) T , i, 1, 5) N 1, i 1, i (%i4) F2(N,F):= 5/F  sum(N*exp(F*t[1,i]),i,1,5) + sum(F*N*t[1,i]*exp(F*t[1,i])*T[1, i],i,1,5)  sum (t[1,i],i,1,5); 5 (%o4) F2(N, F) :=   sum(N exp(( F) t ), i, 1, 5) F 1, i + sum(F N t exp(( F) t ) T , i, 1, 5) 1, i 1, i 1, i  sum(t , i, 1, 5) 1, i (%i5) load (mnewton); (%o5) /home/robert/tmp/maximaclean/maxima/share/contrib/mnewton.mac (%i6) mnewton ([F1(N,F), F2(N,F)], [N, F], [1, 1]); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: Error in PCL::PRINTSTDINSTANCE [or a callee]: Can't print a nonnumber. Fast links are on: do (usefastlinks nil) for debugging Broken at PRINTOBJECT. Type :H for Help. 1 (Continue) Macsyma toplevel 2 (Abort) Return to top level. dbl:MAXIMA>>  end transcript  The error appears to be generated by the line numdet:float(sublis(Solutions,det)), in mnewton.mac. See also bug report 781726.  Comment By: Robert Dodier (robert_dodier) Date: 20060812 10:52 Message: Logged In: YES user_id=501686 Reported behavior not observed in 5.9.3cvs / GCL 2.6.7. Instead mnewton ([F1(N,F), F2(N,F)], [N, F], [1, 1]); => Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bind stack overflow. i.e. different error, and it is caught successfully.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1227953&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 01:50:24

Bugs item #1105366, was opened at 20050119 09:47 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1105366&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SOLVE gives a wrong answer Initial Comment: When I try this: kill(all)$ x(t):=exp(t)*cos(t)$ y(t):=exp(t)*sin(t)$ z(t):=exp(t)*sqrt(3)$ g(t):=[x(t),y(t),z(t)]$ d(t):=sqrt(g(t).g(t))$ d(t)=2; solve(%,t); I get the following output: [t=log(2/sqrt(3)),t=log(2/sqrt(3))] but the correct answer should be t= 0. Using TRIGSIMP or TRIGREDUCE I get te correct answer: trigreduce(d(t)=2); solve(%,t); Now I get: [t = 0] Is this a bug? Franco Buratti (Italy) bufranz@...  Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5   Comment By: Robert Dodier (robert_dodier) Date: 20060803 23:34 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Barton Willis (willisbl) Date: 20050305 02:01 Message: Logged In: YES user_id=895922 Yes, this is a bug. Another solution is t = %i * %pi. Maxima misses that solution after applying trigreduce. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1105366&group_id=4933 
From: SourceForge.net <noreply@so...>  20060909 01:46:48

Bugs item #1045287, was opened at 20041012 06:43 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045287&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 7 Submitted By: Alexander VIDYBIDA (vidybida) Assigned to: Nobody/Anonymous (nobody) Summary: FLOAT(EXP(EXP(2))) does not give a complete answer Initial Comment: Maxima version: 5.9.1 Maxima build date: 17:35 10/8/2004 host type: i586pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 (enableansi) When applied to compositions like EXP(EXP(2)), or EXP(SIN(2)), the FLOAT() function seems unable to get a complete result. If we consider SIN(SIN(2)), or SIN(EXP(2)) instead, the result is complete. (%i1) float(EXP(EXP(2))); 2 %E (%o1) 2.718281828459045 (%i2) float(EXP(SIN(2))); SIN(2) (%o2) 2.718281828459045 (%i3) float(SIN(EXP(2))); (%o3) 0.89385495491281 (%i5) display2d:false$ (%i6) float(EXP(EXP(2))); (%o6) 2.718281828459045^%E^2 (%i7) float(EXP(SIN(2))); (%o7) 2.718281828459045^SIN(2) (%i8) float(SIN(EXP(2))); (%o8) 0.89385495491281  Comment By: Robert Dodier (robert_dodier) Date: 20060729 00:40 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045287&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:47:00

Bugs item #1362658, was opened at 20051121 03:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1362658&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Xmaxima or other UI >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: *generaldisplayprefix* not inserted after questions / FIX Initial Comment: This bug is important for the TeXmacs interface; otherwise, it does not matter. A single chunk of maxima output should have the structure: *generaldisplayprefix* .... *promptprefix* .... *promptsuffix* Think of *generaldisplayprefix* as an opening bracket, *promptprefix* another opening bracket, and *promptsuffix* two closing brackets. Currently, *generaldisplayprefix* is not printed after interactive queries (Is a positive or negative? ot some such). This leads to violations of the TeXmacs communication protocol (unbalanced "brackets"). TeXmacs is permissive enough (now!) to allow this, but it's better to fix this. A proposed fix is attached.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1362658&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:41:30

Bugs item #1407378, was opened at 20060116 07:35 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1407378&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: polarform returns a rectangular expression for float argumen Initial Comment: polarform (1.0 + %i); => 1.414213562373095 (.7071067811865475 %i + .7071067811865476) build_info(); => Maxima version: 5.9.2.19cvs Maxima build date: 16:26 1/15/2006 host type: i686redhatlinuxgnu lispimplementationtype: SBCL lispimplementationversion: 0.9.4 In 5.9.2: polarform (1.0 + %i); => 1.414213562373095 * %e^(0.78539816339745*%i)  Comment By: Raymond Toy (rtoy) Date: 20060201 08:33 Message: Logged In: YES user_id=28849 FWIW, here is a replacement that preserves exponential form. But see also the discussion at http://www.math.utexas.edu/pipermail/maxima/2006/011955.html (defmfun $polarform (xx) (cond ((and (not (atom xx)) (memq (caar xx) '(mequal mlist $matrix))) (cons (car xx) (mapcar #'$polarform (cdr xx)))) (t ((lambda (aas $%emode) (mul (car aas) `((mexpt simp) $%e ,(mul '$%i (cdr aas))))) (absarg xx) nil))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1407378&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:39:14

Bugs item #1409904, was opened at 20060119 06:47 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1409904&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: li[2] and li[3] are only accurate to singleprecision Initial Comment: After examining the code for li2numer and li3numer, we see that the constants used in evaluating these two functions are only accurate to 8 digits or so. li[2](0.5) > 0.5822405249432515 According to mma, the result is 0.58224052646501250590265632  Comment By: Raymond Toy (rtoy) Date: 20060201 08:27 Message: Logged In: YES user_id=28849 A new implementation of li[2] has been added, so li[2] should have doublefloat precision accuracy now. li[2](0.5) > .5822405264650125.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1409904&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:38:12

Bugs item #1430379, was opened at 20060212 18:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: algsys & algebraic == true / FIX Initial Comment: (%o7) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i8) algsys(%,[a,b,c,d]); Maxima encountered a Lisp error: (%i9) algsys(%o7,[a,b,c,d]),algebraic : true; (%o9) [[a=(sqrt(14*%r7*%r8)1)/2, ...]] Would it be OK to have algsys (or maybe just resultant) set algebraic to true? Barton  Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:16 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1.  Comment By: Barton Willis (willisbl) Date: 20060213 04:09 Message: Logged In: YES user_id=895922 Proposed fix: (defmfun $resultant (a b mainvar) (prog (varlist formflag $ratfac res ans genvar $keepfloat $algebraic) (setq varlist (list mainvar) $ratfac t ans 1 $algebraic t) It seems to fix the problem: (%o9) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i10) algsys(%,[a,b,c,d]); (%o10) [[a=(sqrt(14*%r7*%r8)1)/2,b=%r7 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:37:45

Bugs item #1452341, was opened at 20060317 06:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve(x^(5/2)+1,x) produces incorrect roots Initial Comment: Consider: (%i16) display2d:false; (%o16) false (%i17) solve(x^(5/2)+1,x); (%o17) [x = %e^(4*%i*%pi/5),x = %e^(2*%i*%pi/5),x = %e^(2*%i*%pi/5), x = %e^(4*%i*%pi/5),sqrt(x) = 1] (%i18) map(lambda([u],rhs(u)^(5/2)+1),%); (%o18) [2,0,0,2,%i+1] Clearly some of the roots are wrong.  Comment By: Raymond Toy (rtoy) Date: 20060515 07:35 Message: Logged In: YES user_id=28849 This fails because solvespec and solvespec1 (src/solve.lisp) tries to solve y^5+1 = 0 and then x^(1/2) = y, and assumes all the roots are actually roots. More care is needed. This is complicated because solvespec1 calls solve to find the roots, which saves them on the global variable, so we need to examine the global vars to find our roots.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:37:21

Bugs item #1460767, was opened at 20060329 09:23 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1460767&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: psi[n](float) doesn't return a float Initial Comment: psi[0](0.5) doesn't give us a float. But psi[0](1/2) gives 2*log(2)%gamma. A check of the code indicates psi only works with rationals.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1460767&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:22:58

Bugs item #1499447, was opened at 20060602 05:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1499447&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: subscripted additive functions Initial Comment: (%i1) declare(f,additive)$ (%i2) f[a+b](x); Improper name or value in functional position: f[b]+f[a] Yeechs! The function 'f' is additive in its subscript: (%i3) f[a+b]; (%o3) f[b]+f[a] Surely, a subscripted additive function shouldn't be additive in its subscript. Barton  Comment By: Robert Dodier (robert_dodier) Date: 20060604 22:25 Message: Logged In: YES user_id=501686 I agree that subscripted functions should not be additive in their subscripts, but in Maxima the same notation is used for subscripted functions as for memoizing functions, and there's no reason to rule out additive memoizing functions. (Or is there?) I suppose F[a + b](x + y) must be a subscripted function call, but F[a + b] could be either a memoizing function call, or a subscripted function. Even in the case of F[a + b](x + y) could be the return value of a memoizing function applied to x + y.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1499447&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 05:19:57

Bugs item #1552253, was opened at 20060904 16:57 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552253&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima encountered a Lisp error on start Initial Comment: I couldn't run maxima on amd64 gentoo linux system, error is below. I'm ready to provide as much info as you need to fix this problem. Error: >$ maxima Maxima encountered a Lisp error: Error in SETQ [or a callee]: 0 and 2 are illegal as :START and :END for the sequence "". Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Error in SUBSEQ [or a callee]: The tag RETURNFROMDEBUGGER is undefined. Fast links are on: do (usefastlinks nil) for debugging Broken at CONDITIONS::CLCSUNIVERSALERRORHANDLER. 1 (Abort) Return to debug level 1. 2 Return to top level. dbl:MAXIMA>>>:bt #0 CLCSUNIVERSALERRORHANDLER {errorname=:error,correctable=nil,functionname=setq,continueformatstring=(""...} [ihs=14] #1 SUBSEQ {loc0="",loc1=0,loc2=2,loc3=nil} [ihs=13] #2 Computing args for STRINGDOWNCASE {} [ihs=12] #3 SETLOCALE {} [ihs=7] #4 RUN {} [ihs=4] NIL dbl:MAXIMA>>>  >Comment By: Robert Dodier (robert_dodier) Date: 20060907 23:19 Message: Logged In: YES user_id=501686 (0) PLEASE SIGN IN to make bug reports or at least leave your email address so that we can contact you. Thank you & sorry for shouting. (1) Ports other than SBCL, CMUCL, GCL, and Clisp on Linux, and GCL on Windows, are not maintained by the Maxima development team. We don't have the people or the hardware to maintain other ports. Problems in other ports have to be reported to the maintainer for that port. I don't know who that is in the case of the AMD64/Gentoo port. (2) That said, we can glean a bit from the error message. The error originates from SETLOCALE in src/initcl.lisp. There is a test for LOCALE equal to NIL but otherwise LOCALE is assumed to be a nonempty string. LOCALE is a string returned from MAXIMAGETENV. In the case of GCL (which appears to be the Lisp implementation  could be mistaken about that), MAXIMAGETENV punts to SI::GETENV. So a question for the original poster  what does GCL (on your system) return for, say, (SI::GETENV "FOOBAR") (or some other unset environment variable) ? Does it return "" or NIL ? If SI::GETENV returns "", then changing ((null locale) ...) in SETLOCALE (in src/initcl.lisp) to ((or (null locale) (equal locale "")) ...) should fix this problem. You'll have to recompile in order for the change to take effect. Let us know how it turns out. Hope this helps. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552253&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 04:11:20

Bugs item #1554475, was opened at 20060907 20:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1554475&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lisp error Initial Comment: (%i1) 1+1;Maxima encountered a Lisp error: Error in LISP:IF [or a callee]: The function MAYBEINVERT STRINGCASE is undefined.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.  Maxima version: 5.9.1Maxima build date: 7:34 9/24/2004host type: i686pcmingw32lispimplementation type: Kyoto Common Lisplispimplementationversion: GCL 2.6.5   >Comment By: Robert Dodier (robert_dodier) Date: 20060907 22:11 Message: Logged In: YES user_id=501686 I notice that your Maxima version is 5.9.1. There have been many changes since then. Please try the most recent stable version (which as of 2006/09/07 is Maxima 5.9.3) and let us know if it works OK. Version 5.10.0 will be release in a week or two. Maybe you can wait until then.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1554475&group_id=4933 
From: SourceForge.net <noreply@so...>  20060908 02:25:56

Bugs item #1554475, was opened at 20060907 19:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1554475&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lisp error Initial Comment: (%i1) 1+1;Maxima encountered a Lisp error: Error in LISP:IF [or a callee]: The function MAYBEINVERT STRINGCASE is undefined.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.  Maxima version: 5.9.1Maxima build date: 7:34 9/24/2004host type: i686pcmingw32lispimplementation type: Kyoto Common Lisplispimplementationversion: GCL 2.6.5   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1554475&group_id=4933 
From: SourceForge.net <noreply@so...>  20060907 05:17:43

Bugs item #1550985, was opened at 20060902 06:59 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1550985&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: niceindices Initial Comment: Error: (%i1) sum(1/kk,kk,1,n)  sum(1/ii,ii,1,n)$ (%i2) niceindices(%); Maxima encountered a Lisp error: No error: (%i3) sum(1/k,k,1,n)  sum(1/i,i,1,n)$ (%i4) niceindices(%); (%o4) (sum(1/i,i,1,n))sum(1/j,j,1,n) Barton  >Comment By: Barton Willis (willisbl) Date: 20060907 00:17 Message: Logged In: YES user_id=895922 Great! I tested your patch using the test suite. It passes. Barton  Comment By: Andrej Vodopivec (andrejv) Date: 20060904 05:04 Message: Logged In: YES user_id=1179910 I attached a patch for sumcon.lisp which fixes this bug. With this patch (%i2) sum(1/kk,kk,1,n)  sum(1/ii,ii,1,n)$ (%i3) niceindices(%); (%o3) 0 Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1550985&group_id=4933 
From: SourceForge.net <noreply@so...>  20060907 05:13:43

Bugs item #1553866, was opened at 20060907 00:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553866&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: %piargs inconsistent behavior Initial Comment: (1) I can't find documenation for %piargs. (2) The way %piargs works is inconsistent and silly: (%i34) cos(a*x + %pi); (%o34) cos(a*x) (%i35) cos(%pi*x + %pi); (%o35) cos(%pi*x+%pi) < why not cos(%pi*x) ? (3) When %piargs is true, simplifying nfold compositions of trig functions takes O(3^n) time. This is due to the function linearp that does expand and forces a new simplification. Try cos(cos(....(x)))) with %piargs true then with %piargs false. Use about 14 compositions. So making %piargs less silly will also make things like cos(cos(...(x)))) much faster. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553866&group_id=4933 
From: SourceForge.net <noreply@so...>  20060906 13:12:19

Bugs item #1552789, was opened at 20060905 12:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sin(x)^2+1),x,1,1+%pi) takes forever Initial Comment: This is a followon to Bug [ 1044318 ] defint(1/(sin(x)^2+1),x,0,3*%pi) wrong. integrate(1/(sin(x)^2+1),x,1,1+%pi) seems to take forever. But if the limits are 0 and %pi, the integral is evaluated instantly with the correct value.  >Comment By: Raymond Toy (rtoy) Date: 20060906 09:12 Message: Logged In: YES user_id=28849 Looking at the code for ldefint shows why it returns 0. As the docs say, it evaluates the antiderivative and plugs in the limits. I believe this is why defint uses the routine intsubs and samesheetsubs to handle these issues. Perhaps they're not doing what they're supposed to do, but in this particular case, maxima is stuck computing the antiderivative. I don't understand why.  Comment By: Barton Willis (willisbl) Date: 20060906 07:38 Message: Logged In: YES user_id=895922 ldefint gives a wrong answer (basically bug 1044318) (%i10) ldefint(1/(sin(x)^2+1),x,1,1+%pi); (%o10) 0 integrate gives an antiderivative that isn't continuous at odd integer multiples of %pi / 2 (%i11) integrate(1/(sin(x)^2+1),x); (%o11) atan((2*tan(x))/sqrt(2))/sqrt(2) The expression atan(2*tan(x)/sqrt(2))/sqrt(2)+sqrt(2)*%pi*floor(x/%pi1/2)/2 might be a valid antiderivative on all of R provided the first term is assumed left continuous at each odd integer multiple of %pi/2, I think. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&group_id=4933 
From: SourceForge.net <noreply@so...>  20060906 11:38:28

Bugs item #1552789, was opened at 20060905 11:08 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sin(x)^2+1),x,1,1+%pi) takes forever Initial Comment: This is a followon to Bug [ 1044318 ] defint(1/(sin(x)^2+1),x,0,3*%pi) wrong. integrate(1/(sin(x)^2+1),x,1,1+%pi) seems to take forever. But if the limits are 0 and %pi, the integral is evaluated instantly with the correct value.  >Comment By: Barton Willis (willisbl) Date: 20060906 06:38 Message: Logged In: YES user_id=895922 ldefint gives a wrong answer (basically bug 1044318) (%i10) ldefint(1/(sin(x)^2+1),x,1,1+%pi); (%o10) 0 integrate gives an antiderivative that isn't continuous at odd integer multiples of %pi / 2 (%i11) integrate(1/(sin(x)^2+1),x); (%o11) atan((2*tan(x))/sqrt(2))/sqrt(2) The expression atan(2*tan(x)/sqrt(2))/sqrt(2)+sqrt(2)*%pi*floor(x/%pi1/2)/2 might be a valid antiderivative on all of R provided the first term is assumed left continuous at each odd integer multiple of %pi/2, I think. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552789&group_id=4933 
From: SourceForge.net <noreply@so...>  20060906 11:09:28

Bugs item #1553324, was opened at 20060906 06:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: equalp Initial Comment: The user documentation makes me think that is(equalp(a,b)) is the same as is(equal(a,b)), prederror : false. But it isn't: (%i1) is(equalp(x,x)); Maxima was unable to evaluate the predicate: equalp(x,x) (%i2) is(equalp(x,x)), prederror : false; (%o2) unknown If is(equalp(a,b)) is the same as is(equal(a,b)) with prederror : false, do we really need equalp? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1553324&group_id=4933 
From: SourceForge.net <noreply@so...>  20060905 16:15:42

Bugs item #1552710, was opened at 20060905 10:27 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552710&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: product(sum(f(i),i,1,inf),j,1,inf) => inf (wrong) Initial Comment: product(sum(f(i),i,1,inf),j,1,inf) simplifies to inf This is wrong. The simplest counterexample is f(i):=0, where the product = 0. If you want to get fancier, consider f(i):=2^i; product = 1. 5.9.3 Windows GCL  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1552710&group_id=4933 