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}
(12) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

4
(26) 
5
(3) 
6
(10) 
7
(25) 
8
(20) 
9

10
(21) 
11
(10) 
12
(3) 
13
(10) 
14
(7) 
15
(1) 
16
(1) 
17
(1) 
18

19
(15) 
20

21
(1) 
22
(7) 
23
(10) 
24
(10) 
25

26
(1) 
27
(1) 
28
(5) 
29
(26) 
30

31
(30) 





From: SourceForge.net <noreply@so...>  20060713 06:02:01

Bugs item #851436, was opened at 20031129 21:53 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851436&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is/equal fails with varying vrbl ordering Initial Comment: is(equal(rat((x+y+a)^3,x),rat((x+y+a)^3,y))) is "unable to evaluate the predicate". This is really annoying. Equal should at least check whether ratsimp(ab)=0. It is also annoying that equal disreps rat expressions for no good reason. Unfortunately, you can't simply add $equal to (mlist mequal) in simpargs because meqp gets confused. But something like that would be good when someone has the time to test thoroughly.  >Comment By: Robert Dodier (robert_dodier) Date: 20060713 00:02 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=851436&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 06:01:11

Bugs item #850884, was opened at 20031128 13:30 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=850884&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: algsys fails in simple case Initial Comment: eqs: [ v^2  2*v + u^2 + 10*u + 1, v^2  10*v + u^2 + 2*u + 1 ] solve(eqs,[u,v]) => [] But in fact eqs is solvable: eqs1: [ eqs[1], eqs[1]eqs[2] ]; solve(eqs1, [u,v]) => [[u = (sqrt(34) + 6) / 2, v = (sqrt(2)*sqrt(17) + 6) / 2], [u = (sqrt(34)  6) / 2, v = (sqrt(2)*sqrt(17)  6) / 2]] That solution is correct, as you can verify with subst followed by radcan. For that matter, eliminate also works. Maxima 5.9.0/W2k tested with both gcd:subres and gcd:spmod Found starting with a problem report submitted by Kirk Lancaster (27 Nov 2003).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=850884&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 06:00:48

Bugs item #846078, was opened at 20031120 13:02 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=846078&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: facout(a,b) / FIX Initial Comment: facout gives an error when the second argument is an atom (C1) facout(a,b); Error: $b is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> A fix is (defmfun $facout (x y) (ifn (eq 'mplus (and (consp y) (mop y))) y (mul x (addn (mapcar #'(lambda (l) (div l x)) (cdr y)) t)))) Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060713 00:00 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=846078&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:59:38

Bugs item #844521, was opened at 20031118 09: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=844521&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: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: differ.mac has many bugs Initial Comment: differ.mac solves finite difference equations; it has many bugs. And I can't find any user documentation for it either. Specifically It redefines the functions system and eigenvalues (C1) load("differ.mac"); Warning  you are redefining the MACSYMA function EIGENVALUES Warning  you are redefining the MACSYMA function SYSTEM (D1) C:/maxima/Maxima/share/maxima/5.9.0/share/algebra/diff er.mac (C2) display2d : false; (D2) FALSE It solves this one correctly (C3) difference(x[k+1] = x[k] / 5, x[k]); (D3) x[k] = x[0]/5^k But make the equation nonhomogeneous and the solution is wrong (C4) difference(x[k+1] = x[k] / 5 + 1, x[k]); (D4) x[k] = 0 <=== BOGUS I don't think differ.mac can solve nonconstant coefficient equations, but it doesn't check that the coefficients are constant (C5) difference(x[k+1] = k * x[k], x[k]); (D5) x[k] = x[0]*k^k <=== BOGUS It can't solve this degenerate equation (C6) difference(x[k+2] + 2 * x[k+1] + x[k], x[k]); Nonsquare matrix in inverse #0: SYSTEM(eqnlist=[x[k+1] = (x[k+2]+x[k])/2,x[k+1] = x[k+1]],varlist=[x[k+1],x[k]])(differ.mac line 91) #1: second_order_difference(eqn=x[k+1] = (x[k+2]+x [k])/2,var=x[k])(differ.mac line 73) #2: difference(eqn=x[k+2]+2*x[k+1]+x[k],var=x[k]) (differ.mac line 113)  an error. Quitting. To debug this try DEBUGMODE (TRUE);) But the nondegenerate equation is okay (C7) difference(x[k+2] + 8 * x[k+1] + x[k], x[k]); (D7) x[k] = (SQRT(15)4)^k*(SQRT(15)4)*((SQRT(15) + .... differ.mac doesn't check that the equation is linear and may give an incorrect solution when it is (C12) difference(x[k+1]  x[k]^2 + x[k] = 0,x[k]); (D12) x[k] = x[0]*(1)^k((1)^k1)*x[k]^2/2 <== BOGUS Bugs in differ.mac are far too easy to find. I haven't tried recur.mac; maybe it is somewhat better? Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060712 23:59 Message: Logged In: YES user_id=501686 differ package is superseded by solve_rec, which returns valid results (to the best of my knowledge) for the bug examples shown in this report. Also, the solve_rec package is documented. I've moved differ.mac and differ.dem to archive/share/trash/. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=844521&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:31:09

Bugs item #1521613, was opened at 20060713 00:31 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=1521613&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: Documentation Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: user doc for buildq Initial Comment: The last line of the user doc for buildq is wrong: (%i3) show_values (a, b, c  a  b); (%o3) [a = 17, b = 29, c = 1729] It should be [a=17,b=29,cba=1683] Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521613&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:29:13

Bugs item #840848, was opened at 20031112 10:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840848&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: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand doesn't enter unknown functions Initial Comment: trigexpand(f(sin(x)^2)) returns f(sin(x)^2). That is, it doesn't recurse into the arguments of unknown functions. Compare with trigreduce(f(sin(2*x))). Why the discrepancy? If there is a good reason (which I doubt), this behavior should at least be documented, recommending the use of scanmap. I discovered this when trying to simplify an expression involving atan2(...sin(x)^2+cos(x)^2...). Not even atan2 is considered a 'known' function here....  >Comment By: Robert Dodier (robert_dodier) Date: 20060712 23:29 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=840848&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:27:00

Bugs item #1521077, was opened at 20060712 04:48 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521077&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: Invalid Priority: 5 Submitted By: Araceli GÃ¡rate GarcÃa (agarate) Assigned to: Nobody/Anonymous (nobody) Summary: Minimal requirements Initial Comment: Hi, My master degree thesis is a software based on Maxima. I need to know which are the minimal requirements to run maxima in a pc. Could you help me? Thanks in advance Araceli GÃ¡rate Student of CICESE Research Center  >Comment By: Barton Willis (willisbl) Date: 20060713 00:27 Message: Logged In: YES user_id=895922 Please ask your question to the Maxima list: http://maxima.sourceforge.net/maximalist.html You'll get much better advice by asking a question to the Maxima list than filing a bug report. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521077&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:25:19

Bugs item #840360, was opened at 20031111 16:28 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840360&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: qunit(4) internal errors Initial Comment: qunit of a square, e.g. qunit(4), gives the internal error "Floatingpoint exception." It should either give a friendly Maxima error, or possibly return 1  isn't the "quadratic" number field of sqrt(n^2) simply the rationals? qunit(2) goes into an infinite loop. It should give an error, since we're dealing with *real* quadratic number fields, but wouldn't it be nice if...  >Comment By: Robert Dodier (robert_dodier) Date: 20060712 23:25 Message: Logged In: YES user_id=501686 Bugs still present: qunit(4) => division by zero for 5.9.3cvs / gcl 2.6.7, sbcl 0.9.9, clisp 2.38. qunit(2) => infinite loop (same combos).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840360&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:22:03

Bugs item #836708, was opened at 20031105 12:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836708&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rat/tellrat/modulus:2 can return 1 Initial Comment: algebraic:true$ modulus:2$ tellrat(a^2+a)$ rat(a^2) =>  a With modulus=2, 1 is supposed to simplify to 1. This can be fixed (bizarrely) by ev: ev(%) => a  >Comment By: Robert Dodier (robert_dodier) Date: 20060712 23:22 Message: Logged In: YES user_id=501686 Observed w/ 5.9.3cvs / gcl 2.6.7, but not 5.9.3cvs / sbcl 0.9.9 or clisp 2.38.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 10:38 Message: Logged In: YES user_id=581700 On both SBCL and CLISP I get the expected result (C4) rat(a^2); (D4)/R/ a I'd guess this is the same GCL specific misfeature as #706562 (mod(2,4) => 2 not 2).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836708&group_id=4933 
From: SourceForge.net <noreply@so...>  20060713 05:18:47

Bugs item #836704, was opened at 20031105 11:56 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836704&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: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gendiff is all bugs: should be deprecated Initial Comment: The gendiff package only gets the most trivial cases right, and should probably be deprecated until it is fixed. load("gendif") gendiff(x,x,n) => 'diff(x,x,n) which is correct, except that gendiff is supposed to give an explicit form *without* 'diff's. After all, it does it for x^2: genfact(2,n,1)*x^(2n) so why doesn't it give genfact(1,n,1)*x^(1n) in this case? Sure, that's clumsy, but it's explicit.  gendiff((x1)^2,x,n) => 0 (!!) The ratexpand in gendiffpow is presumably supposed to be ratexpand(x1^x2); but though that fix works in this particular case, it doesn't work for sin(x)^2.  q: gendiff(x*(x+1),x,n) => 'DIFF(x,x,n)*'SUM(BINOMIAL(n,I)*'DIFF(x,x,I),I,0,n) which looks very impressive, but is wrong. In particular, subst(0,n,q) => x^2 (!!) and subst(1,n,q) => (x+1) (!!). Correct answers are of course x*(x+1) and 2*x+1.  gendiff(x^x,x,n) => x^(xn)*GENFACT(x,n,1) (!!) but diff(x^x,x,1) => x^x*(log(x)+1) (OK) gendiff is assuming that all powers are free of the differentiation variable. To fix, add a freeof clause in gendiffpow: ...if x1=x <<<and freeof(x,x2)>>> then ...  gendiff is also pretty limited, not even handling sin(x) ===> sin(x+n*%pi/2) sinh(x) ===> (%e^x+(1)^n*%e^x)/2 (also expressible as pure hyperbolics)  >Comment By: Robert Dodier (robert_dodier) Date: 20060712 23:18 Message: Logged In: YES user_id=501686 Testing w/ 5.9.3cvs shows all reported bugs still present. Moved share/calculus/gendif.mac to archive/share/trash/gendif.mac. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20050303 09:21 Message: Logged In: YES user_id=501686 I've commented out the description of gendiff in doc/info/Differentiation.texi pending resolution of this bug report.  Comment By: Robert Dodier (robert_dodier) Date: 20050303 09:13 Message: Logged In: YES user_id=501686 For the historical record, I'm copying the following bug report from share/calculus/gendif.usg: >From "ADK@... 04/12/82 9:04pm": "(1) gendiff(x*(xa),x,j); [...] (2) The answer for the above example involves the silly quantity diff(x,x,i), which is clearly kdelta(i1)+x*kdelta(i) for positive integer values of i. This information should be used by SUM as well." I've verified that in current cvs Maxima, gendiff(x*(xa),x,j) yields an expression involving diff(x,x,i) as noted. I've elided from (1) a report about a bug that has apparently gone away  "This asks ``Is J  I an integer?'', which is hard for the user to answer as I is a system generated dummy summation index (which has, in general, indefinite sign anyhow)." Maxima version: 5.9.1.1cvs Maxima build date: 20:47 3/2/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.31 (released 20030901)  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031106 14:49 Message: Logged In: YES user_id=581700 > q: gendiff(x*(x+1),x,n) => > 'DIFF(x,x,n)*'SUM(BINOMIAL(n,I)*'DIFF(x,x,I),I,0,n) > > which looks very impressive, but is wrong. Just a case sensitivity bug. Here's a simpler example: (C2) gendiff(x+1,x,k); n d x (D2)  n dx $N is bound to $k but $n, which is passed to the recursive calls to $GENDIFF, is not. I propose to just upcase the whole file. Downcasing would also be possible, but in this case we would probably want to keep the name GENDIFF itself uppercase, such that gendiff(...) and GENDIFF(...) both work. I prefer upcasing also because this way people may spot more easily what changed (most of the file content being uppercase).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836704&group_id=4933 