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}
(11) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(2) 
3
(1) 
4

5
(2) 
6

7

8
(7) 
9
(6) 
10

11

12

13

14

15
(1) 
16
(2) 
17

18

19
(6) 
20

21
(3) 
22
(2) 
23
(1) 
24
(1) 
25

26
(2) 
27
(1) 
28

29
(2) 
30


From: SourceForge.net <noreply@so...>  20040429 18:03:49

Bugs item #944743, was opened at 20040429 13:03 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=944743&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: poly_discriminant with ratfac == true / FIX Initial Comment: When ratfac == true, poly_discriminant often incorrectly determines that the first argument is nonpolynomial; for example (C1) ratfac : true$ (C2) poly_discriminant((x1)*(x2),x); ARG. MUST BE A POLYNOMIAL IN VAR  an error. Quitting. To debug this try DEBUGMODE (TRUE);) Additionally, (1) The error message is silly. (2) The function poly_discriminant isn't documented. (3) What other functions misbehave when ratfac == true? A simple fix is (DEFMFUN $POLY_DISCRIMINANT (POLY VAR) (LET* ((VARLIST (LIST VAR)) ($ratfac nil) (GENVAR ()) (RFORM (RFORM ($rat POLY var))) (RVAR (CAR (LAST GENVAR))) (N (PDEGREE (SETQ POLY (CAR RFORM)) RVAR))) (COND ((= N 1) 1) ((OR (= N 0) (NOT (atom (CDR RFORM)))) (MERROR "The first argument must be a polynomial in ~:M" var)) (T (PDIS (PRESIGN (// (f* N (f1 N)) 2) (PQUOTIENT (RESULTANT POLY (PDERIVATIVE POLY RVAR)) (PLC POLY)))))))) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=944743&group_id=4933 
From: SourceForge.net <noreply@so...>  20040429 16:17:34

Bugs item #944637, was opened at 20040429 09:17 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=944637&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Difference between GCL  CLISP for differentiating Initial Comment: Submitted by faisant@... output of bug_report() : Maxima version: 5.9.0 Maxima build date: 22:32 3/17/2004 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.31 (released 20030901) (built 3273145223) (memory 3288547952) (on Linux) Bug : (C2) integrate(%e^t/(1+%e^(2*t)),t); t (D2) ATAN(%E ) (C3) diff(%,t); d t (D3)  (ATAN(%E )) dt But no problem with xmaxima with gcl on WinXP: (C1) integrate(%e^x/(1+%e^(2*x)),x); x (D1) ATAN(%E ) (C2) diff(atan(%e^x),x); x %E (D2)  2 x %E + 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=944637&group_id=4933 
From: SourceForge.net <noreply@so...>  20040427 13:19:15

Bugs item #942261, was opened at 20040426 07:09 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=942261&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta(1) returns 1/12 instead of 1/12 Initial Comment: The Riemann zeta function at 1 takes the value 1/12 (see (69) in http://mathworld.wolfram.com/RiemannZetaFunction.html, or use Cauchy's residue theorem on the representation of zeta(z) as an integral around the Hankel contour). However, in maxima, the call zeta(1) returns 1/12. Thanks, Jamie Walker jamie@...  >Comment By: Barton Willis (willisbl) Date: 20040427 08:19 Message: Logged In: YES user_id=895922 I've attached tests for the zeta function. Barton  Comment By: Barton Willis (willisbl) Date: 20040426 12:48 Message: Logged In: YES user_id=895922 Attached is a fix for zeta. The code could be improved in several ways. For one, zeta should simplify instead of evaluate. Also zeta should work for floating point arguments. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=942261&group_id=4933 
From: SourceForge.net <noreply@so...>  20040426 17:48:50

Bugs item #942261, was opened at 20040426 07:09 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=942261&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta(1) returns 1/12 instead of 1/12 Initial Comment: The Riemann zeta function at 1 takes the value 1/12 (see (69) in http://mathworld.wolfram.com/RiemannZetaFunction.html, or use Cauchy's residue theorem on the representation of zeta(z) as an integral around the Hankel contour). However, in maxima, the call zeta(1) returns 1/12. Thanks, Jamie Walker jamie@...  >Comment By: Barton Willis (willisbl) Date: 20040426 12:48 Message: Logged In: YES user_id=895922 Attached is a fix for zeta. The code could be improved in several ways. For one, zeta should simplify instead of evaluate. Also zeta should work for floating point arguments. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=942261&group_id=4933 
From: SourceForge.net <noreply@so...>  20040426 12:09:29

Bugs item #942261, was opened at 20040426 05: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=942261&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta(1) returns 1/12 instead of 1/12 Initial Comment: The Riemann zeta function at 1 takes the value 1/12 (see (69) in http://mathworld.wolfram.com/RiemannZetaFunction.html, or use Cauchy's residue theorem on the representation of zeta(z) as an integral around the Hankel contour). However, in maxima, the call zeta(1) returns 1/12. Thanks, Jamie Walker jamie@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=942261&group_id=4933 
From: SourceForge.net <noreply@so...>  20040424 19:21:42

Bugs item #941457, was opened at 20040424 14:21 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=941457&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/x^5,x,1,2^(1/78)) Initial Comment: In addition to bug 938235, here is another similar bug. I did these calculations after applying my gfactor patch. These are okay: (C2) integrate(1/x^5,x,1,sqrt(2)); (D2) 3/16 (C3) integrate(1/x^5,x,1,2^(1/23)); (D3) (2^(4/23)1)/(4*2^(4/23)) But we get a quotient by zero error for (C4) integrate(1/x^5,x,1,2^(1/78)); QUOTIENT by ZERO Changing gcd and algebraic doesn't help (C5) algebraic : true$ (C6) gcd : 'spmod$ (C7) integrate(1/x^5,x,1,2^(1/78)); QUOTIENT by ZERO (C8) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 13:6 4/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=941457&group_id=4933 
From: SourceForge.net <noreply@so...>  20040423 16:08:24

Bugs item #940835, was opened at 20040423 12:08 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=940835&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform fails with float/numer flags Initial Comment: rectform(log(%i)) => %i*%pi/2 OK float(rectform(log(%i))) => 1.57 * %i OK rectform(log(%i)),numer => 4.71 * %i NO! rectform(log(%i)),float => fatal error The problem is the function 2pistrip.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=940835&group_id=4933 
From: SourceForge.net <noreply@so...>  20040422 16:41:36

Bugs item #938235, was opened at 20040419 18:02 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Claudio (gabryuri) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1/2)*u^21/u^5,u,1,sqrt(2)); is not correct... Initial Comment: Sorry, but in the integral (1/2)*u^21/u^5 with u=1 to sqrt(2) them Maxima program return SQRT(2) 1    3 6 Maxima comand: integrate((1/2)*u^21/u^5,u,1,sqrt (2)); But the answer correct is: sqrt(2) 17    3 48 See in MuPad, Maple or Mathematica. sorry by english. Luis Cláudio  Brasilia  Brazil. luis_claudio2000@...  >Comment By: Barton Willis (willisbl) Date: 20040422 11:41 Message: Logged In: YES user_id=895922 I thought of a fix that isn't terrible. I inserted a call to gfactor in solvecases. I also put an merror into polelistthis way a user will get an error instead of a wrong value should solvecases ever fail. The gfactor fix seems to fix this problem. Barton  Comment By: Barton Willis (willisbl) Date: 20040422 11:03 Message: Logged In: YES user_id=895922 To integrate 1/x^5 from 1 to sqrt(s), Maxima makes a change of variable and then it uses residues. But when 'solvecase' fails to find the poles, it returns failure and polelist returns nil. After that 'res' believes that there are no poles so the sum of the residues vanishes. I can put a trap in initialanalysis that catches more easy cases and prevents Maxima from using the residue methodI don't have a fix for the real problem. (C4) integrate(1/x^5,x,1,sqrt(2)); 1> (POLELIST ((MPLUS SIMP IRREDUCIBLE FACTORED) 1 ((MTIMES SIMP RATSIMP) 5 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) $x) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 2)) ((MTIMES SIMP) 20 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 3)) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 4)) ((MTIMES SIMP) 4 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 5))) #<compiledclosure 108d7e8c> #<compiledclosure 108d7ea8>) 2> (SOLVECASE ((MPLUS SIMP IRREDUCIBLE FACTORED) 1 ((MTIMES SIMP RATSIMP) 5 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) $x) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 2)) ((MTIMES SIMP) 20 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 3)) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 4)) ((MTIMES SIMP) 4 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 5)))) <2 (SOLVECASE FAILURE) <1 (POLELIST NIL) (D4) 0 (C5) Compare this to (C5) integrate(1/x^5,x,1,2); 1> (POLELIST ((MEXPT SIMP FACTORED) ((MPLUS SIMP IRREDUCIBLE) 1 ((MTIMES SIMP RATSIMP) 2 $x)) 5) #<compiledclosure 108d7e8c> #<compiledclosure 108d7ea8>) 2> (SOLVECASE ((MEXPT SIMP FACTORED) ((MPLUS SIMP IRREDUCIBLE) 1 ((MTIMES SIMP RATSIMP) 2 $x)) 5)) <2 (SOLVECASE (((MEQUAL SIMP) $x ((RAT SIMP) 1 2)) 5)) <1 (POLELIST ((((RAT SIMP) 1 2) ((MEXPT SIMP) ((MPLUS SIMP) ((RAT SIMP) 1 2) $x) 5)) ((((RAT SIMP) 1 2) 5)) NIL NIL)) (c6) 15 / 64 (DEFUN POLELIST (D REGION REGION1) (PROG (ROOTS $BREAKUP R RR SS R1 S POLE WFLAG CF) (SETQ WFLAG T) (SETQ LEADCOEF (POLYINX D VAR 'LEADCOEF)) (SETQ ROOTS (SOLVECASE D)) (if (eq roots 'failure) (return ())) ;; < this is a trouble maker for res LOOP1 (COND ((NULL ROOTS) (COND ((AND SEMIRAT Barton  Comment By: Barton Willis (willisbl) Date: 20040421 09:48 Message: Logged In: YES user_id=895922 Thank you for reporting this bug; I suspect that the following bug is related to the one you found. (C2) integrate(1/x^5,x,1,sqrt(2)); (D2) 0 (C3) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 8:30 4/21/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 If you find more Maxima bugs, please report them. Regards, Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 
From: SourceForge.net <noreply@so...>  20040422 16:03:15

Bugs item #938235, was opened at 20040419 18:02 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Claudio (gabryuri) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1/2)*u^21/u^5,u,1,sqrt(2)); is not correct... Initial Comment: Sorry, but in the integral (1/2)*u^21/u^5 with u=1 to sqrt(2) them Maxima program return SQRT(2) 1    3 6 Maxima comand: integrate((1/2)*u^21/u^5,u,1,sqrt (2)); But the answer correct is: sqrt(2) 17    3 48 See in MuPad, Maple or Mathematica. sorry by english. Luis Cláudio  Brasilia  Brazil. luis_claudio2000@...  >Comment By: Barton Willis (willisbl) Date: 20040422 11:03 Message: Logged In: YES user_id=895922 To integrate 1/x^5 from 1 to sqrt(s), Maxima makes a change of variable and then it uses residues. But when 'solvecase' fails to find the poles, it returns failure and polelist returns nil. After that 'res' believes that there are no poles so the sum of the residues vanishes. I can put a trap in initialanalysis that catches more easy cases and prevents Maxima from using the residue methodI don't have a fix for the real problem. (C4) integrate(1/x^5,x,1,sqrt(2)); 1> (POLELIST ((MPLUS SIMP IRREDUCIBLE FACTORED) 1 ((MTIMES SIMP RATSIMP) 5 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) $x) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 2)) ((MTIMES SIMP) 20 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 3)) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 4)) ((MTIMES SIMP) 4 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 5))) #<compiledclosure 108d7e8c> #<compiledclosure 108d7ea8>) 2> (SOLVECASE ((MPLUS SIMP IRREDUCIBLE FACTORED) 1 ((MTIMES SIMP RATSIMP) 5 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) $x) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 2)) ((MTIMES SIMP) 20 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 3)) ((MTIMES SIMP) 20 ((MEXPT SIMP RATSIMP) $x 4)) ((MTIMES SIMP) 4 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) ((MEXPT SIMP RATSIMP) $x 5)))) <2 (SOLVECASE FAILURE) <1 (POLELIST NIL) (D4) 0 (C5) Compare this to (C5) integrate(1/x^5,x,1,2); 1> (POLELIST ((MEXPT SIMP FACTORED) ((MPLUS SIMP IRREDUCIBLE) 1 ((MTIMES SIMP RATSIMP) 2 $x)) 5) #<compiledclosure 108d7e8c> #<compiledclosure 108d7ea8>) 2> (SOLVECASE ((MEXPT SIMP FACTORED) ((MPLUS SIMP IRREDUCIBLE) 1 ((MTIMES SIMP RATSIMP) 2 $x)) 5)) <2 (SOLVECASE (((MEQUAL SIMP) $x ((RAT SIMP) 1 2)) 5)) <1 (POLELIST ((((RAT SIMP) 1 2) ((MEXPT SIMP) ((MPLUS SIMP) ((RAT SIMP) 1 2) $x) 5)) ((((RAT SIMP) 1 2) 5)) NIL NIL)) (c6) 15 / 64 (DEFUN POLELIST (D REGION REGION1) (PROG (ROOTS $BREAKUP R RR SS R1 S POLE WFLAG CF) (SETQ WFLAG T) (SETQ LEADCOEF (POLYINX D VAR 'LEADCOEF)) (SETQ ROOTS (SOLVECASE D)) (if (eq roots 'failure) (return ())) ;; < this is a trouble maker for res LOOP1 (COND ((NULL ROOTS) (COND ((AND SEMIRAT Barton  Comment By: Barton Willis (willisbl) Date: 20040421 09:48 Message: Logged In: YES user_id=895922 Thank you for reporting this bug; I suspect that the following bug is related to the one you found. (C2) integrate(1/x^5,x,1,sqrt(2)); (D2) 0 (C3) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 8:30 4/21/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 If you find more Maxima bugs, please report them. Regards, Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 
From: SourceForge.net <noreply@so...>  20040421 14:48:04

Bugs item #938235, was opened at 20040419 18:02 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Claudio (gabryuri) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1/2)*u^21/u^5,u,1,sqrt(2)); is not correct... Initial Comment: Sorry, but in the integral (1/2)*u^21/u^5 with u=1 to sqrt(2) them Maxima program return SQRT(2) 1    3 6 Maxima comand: integrate((1/2)*u^21/u^5,u,1,sqrt (2)); But the answer correct is: sqrt(2) 17    3 48 See in MuPad, Maple or Mathematica. sorry by english. Luis Cláudio  Brasilia  Brazil. luis_claudio2000@...  >Comment By: Barton Willis (willisbl) Date: 20040421 09:48 Message: Logged In: YES user_id=895922 Thank you for reporting this bug; I suspect that the following bug is related to the one you found. (C2) integrate(1/x^5,x,1,sqrt(2)); (D2) 0 (C3) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 8:30 4/21/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 If you find more Maxima bugs, please report them. Regards, Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 
From: SourceForge.net <noreply@so...>  20040421 12:47:21

Bugs item #676920, was opened at 20030129 12:47 Message generated for change (Comment added) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=676920&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: severe radcan bug Initial Comment: the following exhibits a bug (probably) in radcan (C1) p(u,k):=u^(1)+u^k; (C1)  1 k (D1) p(u, k) := u + u (C2) p1(u,k):=at(diff(p('u,k),'u),['u=u]); (D2) p1(u, k) := AT(DIFF(p('u, k), 'u), ['u = u]) (C3) p2(u,k):=at(diff(p('u,k),'u,2),['u=u]); (D3) p2(u, k) := AT(DIFF(p('u, k), 'u, 2), ['u = u]) (C4) tau:subst(solve(p1(u,k),u),u); Is k an integer? y; 1 (D4)  1  k + 1 k (C5) radcan(p(tau,k)/p2(tau,k)); k + 1 (D5)  k + 3 2   k + 1 k + 1 2 2 k + k (k  k)  which is correct  (C6) radcan(sqrt(%)); SQRT(k + 1) (D6)  1  k + 1 2 k SQRT(k + k)  which is bogus, evaluate D5 and D6 at k=2 for example  (C7) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  Maxima version: 5.9.0rc3 Maxima build date: 21:0 11/26/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  The above information is also available from the Maxima function build_info(). maybe this is related to bug no 635338: http://sourceforge.net/tracker/index.php?func=detail&aid=635338&group_id=4933&atid=104933  Comment By: Viktor Toth (vttoth) Date: 20040421 08:47 Message: Logged In: YES user_id=1023504 I don't see the bug here, the result appears to be correct actually. D6 is the square root of the D5 expression, which is what it should be, or am I missing something? Viktor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=676920&group_id=4933 
From: SourceForge.net <noreply@so...>  20040421 02:37:59

Bugs item #939022, was opened at 20040420 22:37 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=939022&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: matrix(...taylor...)^^1 wrong Initial Comment: Consider m: matrix([taylor(1+a*x,x,0,1),0], [0,taylor(1+d*x,x,0,1)]); Now, m^^1 => matrix([1/(d*x+1),0],[0,1/(d*x+1)]) There are two problems with this. First, the answer is incorrect. Compare: matrixmap(ratdisrep,m)^^1 => matrix([1/(a*x+1),0],[0,1/(d*x+1)]) Second, the answer is not in terms of taylor series. A silent ratdisrep was done in the middle, losing truncation information.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=939022&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 23:25:05

Bugs item #932076, was opened at 20040408 19:06 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932076&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ode2( 'diff(y,x)=%i*y+sin(x), y, x) => div by 0 Initial Comment: ode2( 'diff(y,x)=%i*y+sin(x), y, x) gives division by 0  >Comment By: Stavros Macrakis (macrakis) Date: 20040419 19:25 Message: Logged In: YES user_id=588346 Same problem if you solve the equation 'diff(y,x)= k*y+sin(x)  the solution is not valid at k=%i, but it doesn't ask. Correct solution for k=%i is y = ((x%i*%c%i)*sin(x)+(%i*x%c)*cos(x))/2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932076&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 23:02:15

Bugs item #938235, was opened at 20040419 20:02 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=938235&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Claudio (gabryuri) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1/2)*u^21/u^5,u,1,sqrt(2)); is not correct... Initial Comment: Sorry, but in the integral (1/2)*u^21/u^5 with u=1 to sqrt(2) them Maxima program return SQRT(2) 1    3 6 Maxima comand: integrate((1/2)*u^21/u^5,u,1,sqrt (2)); But the answer correct is: sqrt(2) 17    3 48 See in MuPad, Maple or Mathematica. sorry by english. Luis Cláudio  Brasilia  Brazil. luis_claudio2000@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938235&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 22:50:16

Bugs item #659288, was opened at 20021228 01:02 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=659288&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: limit(atan(tan(x)^2),x,inf)=>Internal er Initial Comment: limit(atan(tan(x)^2),x,inf); SIGN called on UND.  an error. The correct answer is of course IND  the limit set is [0,%pi/2). Presumably what is happening here is that there is an intermediate calculation of limit(tan(x)^2,x,inf).  >Comment By: Stavros Macrakis (macrakis) Date: 20040419 18:50 Message: Logged In: YES user_id=588346 limit(atan(und)) also gets Sign called on UND. Of course, onearg limit is not advertised to work with UND, but internally it seems likely that this is what it is doing.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=659288&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 20:00:48

Bugs item #938134, was opened at 20040419 16:00 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=938134&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: diff(realpart) bogus Initial Comment: declare(z,complex)$ diff(realpart(z),z) => realpart(1) ?!?! Realpart is nowhere differentiable!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938134&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 19:55:20

Bugs item #935030, was opened at 20040414 12:17 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp with algebraic == true Initial Comment: With algebraic == true, ratsimp doesn't fully simplify some expressions. Here is an example (C1) display2d : false$ (C2) algebraic : true$ (C3) integrate(1/(2+x^3),x)$ (C4) ratsimp(diff(%,x)); (D4) 4*2^(2/3)/(4*2^(2/3)*x^3+8*2^(2/3)) (C5) ratsimp(%); (D5) 1/(x^3+2) Maybe this is the purpose of fullratsimp, but it seems odd that ratsimp fails to cancel the factor of 2^(2/3). I discovered this when I ran run_testsuite with algebraic == true. (C6) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 7:58 4/5/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040419 15:55 Message: Logged In: YES user_id=588346 Though this is annoying and surprising, it *is* documented: >>>>>>>>>(fullratsimp) When nonrational expressions are involved, one call to RATSIMP followed as is usual by nonrational ("general") simplification may not be sufficient to return a simplified result. <<<<<<<<< Also, the algebraic flag only changes the behavior with gcd=spmod. With gcd=subres (the default), you need two ratsimp's regardless of the setting of algebraic.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 
From: SourceForge.net <noreply@so...>  20040419 19:49:51

Bugs item #884300, was opened at 20040125 13:57 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve and ALL Initial Comment: Solve/algsys is inconsistent in how it represents the solution "all values satisfy the equation": solve([x=x],x) returns ALL solve([y=y],x) returns ALL solve([x=x],[x]) returns ALL solve([x=x],[x,y]) returns [[x = %R10, y = %R9]] solve([],[x]) returns [] First of all, the last case is simply wrong. The solution to "find all x such that the empty set of constraints is satisfied" is "all x", not "no x" (which is what [] means). After all, the y=y case above includes an equation which doesn't even mention x. The other cases are inconsistent. We should use one or the other. The %R10 approach (from algsys) seems better, because it is completely consistent with the non all case. Any program using Solve will have to make a special case for ALL otherwise. I would also argue that SOLVE_INCONSISTENT_ERROR should default to FALSE. That is, inconsistent systems should return [], not give an error.  >Comment By: Stavros Macrakis (macrakis) Date: 20040419 15:49 Message: Logged In: YES user_id=588346 A similar problem: solve( (x1)^2 = (1x)^2 , x) returns [x=x] and not ALL. This is actually worse than an inconsistency: since x appears on both sides of the solution, a calling program will assume that Solve failed to find a solution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 
From: SourceForge.net <noreply@so...>  20040416 18:07:15

Bugs item #936494, was opened at 20040416 12:33 Message generated for change (Comment added) made by amundson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=936494&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: hubert (hubertst) Assigned to: Nobody/Anonymous (nobody) Summary: diff is not evaluated Initial Comment: Hi, I have installed Maxima 5.9.0 on several computers under Linux, with Clisp 2.31 and 2.33. Nowhere the 'diff' command produces the expected result, more precisely, the result is not evaluated. This works: (C1) diff(sin(x)); (D1) COS(x) DEL(x) but this doesn't: (C2) diff(sin(x),x); d (D2)  (SIN(x)) dx Is it a bug in Maxima, Clisp, an incomplete installation or an incorrect configuration? I tried to find an answer on Internet but I failed. Anybody has a hint? Thanks in advance. Hubert  >Comment By: James Amundson (amundson) Date: 20040416 13:07 Message: Logged In: YES user_id=28457 Maxima 5.9.0 is incompatible with clisp versions > 2.29. If you run "make check" with Clisp 2.31 or 2.33, you will see many errors. The problem has been fixed in cvs. Either get an old version of clisp or grab the most recent Maxima snapshot from the Sourceforge project page.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=936494&group_id=4933 
From: SourceForge.net <noreply@so...>  20040416 17:33:34

Bugs item #936494, was opened at 20040416 19:33 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=936494&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hubert (hubertst) Assigned to: Nobody/Anonymous (nobody) Summary: diff is not evaluated Initial Comment: Hi, I have installed Maxima 5.9.0 on several computers under Linux, with Clisp 2.31 and 2.33. Nowhere the 'diff' command produces the expected result, more precisely, the result is not evaluated. This works: (C1) diff(sin(x)); (D1) COS(x) DEL(x) but this doesn't: (C2) diff(sin(x),x); d (D2)  (SIN(x)) dx Is it a bug in Maxima, Clisp, an incomplete installation or an incorrect configuration? I tried to find an answer on Internet but I failed. Anybody has a hint? Thanks in advance. Hubert  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=936494&group_id=4933 
From: SourceForge.net <noreply@so...>  20040415 19:40:54

Bugs item #935030, was opened at 20040414 11:17 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=935030&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp with algebraic == true Initial Comment: With algebraic == true, ratsimp doesn't fully simplify some expressions. Here is an example (C1) display2d : false$ (C2) algebraic : true$ (C3) integrate(1/(2+x^3),x)$ (C4) ratsimp(diff(%,x)); (D4) 4*2^(2/3)/(4*2^(2/3)*x^3+8*2^(2/3)) (C5) ratsimp(%); (D5) 1/(x^3+2) Maybe this is the purpose of fullratsimp, but it seems odd that ratsimp fails to cancel the factor of 2^(2/3). I discovered this when I ran run_testsuite with algebraic == true. (C6) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 7:58 4/5/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 
From: SourceForge.net <noreply@so...>  20040409 19:38:37

Bugs item #928407, was opened at 20040402 11:44 Message generated for change (Comment added) made by willisb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928407&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(x+a),x) missing abs Initial Comment: presently integrate(1/(x+a),x) returns log(x+a) It should return log(abs(x + a))  Comment By: Barton Willis (willisb) Date: 20040409 14:38 Message: Logged In: YES user_id=570592 On the reals integrate(1/x,x) == log(abs(x)) is okay, but on the complex plane, it's wrong. For one, abs isn't differentiable anywhere in the complex plane. If you run into a problem and think you need log(abs( .... )), try logcontract. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928407&group_id=4933 
From: SourceForge.net <noreply@so...>  20040409 17:17:42

Bugs item #932395, was opened at 20040409 13:17 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=932395&group_id=4933 Category: None 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...>  20040409 14:05:01

Bugs item #932302, was opened at 20040409 09:45 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932302&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: partfrac/ratnumer of taylor bad: taychk2rat/FIX Initial Comment: expr: 1/(x^21)$ texpr: taylor(expr,x,1,1)$ ptexpr: partfrac(texpr,x) => (x+4/(x1)3)/8 NO! This is algebraically correct, but not in partfrac form. The correct answer is given by: partfrac(ratdisrep(texpr),x) == partfrac(ptexpr,x) => 1/(2*(x1))+(x3)/8 The immediate fix is to replace (DESETQ (RATFORM . EXP) (TAYCHK2RAT EXP)) with (DESETQ (RATFORM . EXP) (RATF (TAYCHK2RAT EXP))) however, I wonder if TAYCHK2RAT shouldn't be doing this. Compare: ratnumer(taylor(x+1/x,x,0,1)) => x+1/x ???  >Comment By: Stavros Macrakis (macrakis) Date: 20040409 10:05 Message: Logged In: YES user_id=588346 taychk2rat is used in four places in Maxima: ratnumer ratdenom partfrac horner In all of them, it would be better if taychk2rat performed the ratf. So the fix should be in taychk2rat, not in the callers. Or maybe in $taytorat. I don't understand what srrat does  is that the problem? Maybe look at this later.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932302&group_id=4933 
From: SourceForge.net <noreply@so...>  20040409 13:45:22

Bugs item #932302, was opened at 20040409 09:45 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=932302&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac of taylor bogus taychk2rat/FIX Initial Comment: expr: 1/(x^21)$ texpr: taylor(expr,x,1,1)$ ptexpr: partfrac(texpr,x) => (x+4/(x1)3)/8 NO! This is algebraically correct, but not in partfrac form. The correct answer is given by: partfrac(ratdisrep(texpr),x) == partfrac(ptexpr,x) => 1/(2*(x1))+(x3)/8 The immediate fix is to replace (DESETQ (RATFORM . EXP) (TAYCHK2RAT EXP)) with (DESETQ (RATFORM . EXP) (RATF (TAYCHK2RAT EXP))) however, I wonder if TAYCHK2RAT shouldn't be doing this. Compare: ratnumer(taylor(x+1/x,x,0,1)) => x+1/x ???  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932302&group_id=4933 