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}
(53) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2
(2) 
3
(1) 
4
(4) 
5
(2) 
6

7

8
(2) 
9

10
(2) 
11

12
(1) 
13

14
(2) 
15

16
(3) 
17

18

19

20
(2) 
21
(1) 
22

23
(1) 
24

25
(3) 
26

27

28
(6) 
29

30
(1) 
31




From: SourceForge.net <noreply@so...>  20040305 06:47:18

Bugs item #910270, was opened at 20040305 01:32 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=910270&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1/+3*x parses as 1/(+3*x) Initial Comment: A plus sign immediately following a multiplicative operator causes the next multiplicative term to bind tightly: 1/+3*x == 1/(+3*x) == 1/(3*x) (!!) should be (1/3)*x 1/+x/3 == 1/(+x/3) == 3/x (!!) should be (1/+x)/3 = 1/(3*x) a^+b*c == a^+(b*c) (!!) should be (a^b)*c With negative signs, these parse correctly: 1/3*x == (1/3)*x == x/3 1/x/3 == (1/x)/3 == 1/(3*x) a^b*c == (a^b)*c == c/(a^b) Maxima 5.9.0 on GCL 2.5.0 mingw32 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=910270&group_id=4933 
From: SourceForge.net <noreply@so...>  20040304 23:14:42

Bugs item #908650, was opened at 20040302 18:47 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908650&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: eigenvectors() wipes out on 3x3 Initial Comment: Maxima version: 5.9.0.1cvs Maxima build date: 1:57 2/8/2004 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.32 (20031229) (built 3285189666) (memory 3285212279) eigenvectors(m1) just chews CPU on this matrix: (C4) m1 : matrix([a,b,c],[d,e,f],[g,h,0]); on the following it fails with a message (C5) m1 : matrix([k1,k2,k3],[k1,k2,k4],[k3,k4,0]); [  k1 k2  k3 ] [ ] (D5) [ k1  k2  k4 ] [ ] [ k3 k4 0 ] (C6) eigenvectors(m1); Quotient by a polynomial of higher degree #0: EIGENVECTORS(mat=MATRIX([k1,k2,k3],[k1,k2,k4],[k3,k4,0]))(eigen.mac line 122)  an error. Quitting. To debug this try DEBUGMODE(TRUE);)  >Comment By: Stavros Macrakis (macrakis) Date: 20040304 18:00 Message: Logged In: YES user_id=588346 As Barton says, the eigenvalues are a mess, so there's not much chance of finding eigenvectors unless you can somehow simplify them. See describe(eigenvectors) and describe(eigenvalues) for some ideas. But I am not optimistic. Even with k1=1, k4=0, the eigenvectors are fairly messy. (Quotient/polynomial is still a bug in Subres GCD, probably the same as has been reported before; with gcd:'spmod, it runs for a long time (forever?) but doesn't crash.)  Comment By: Barton Willis (willisbl) Date: 20040304 13:13 Message: Logged In: YES user_id=895922 Maxima finds the eigenvalues okay  they are huge ugly expressions with nested square roots and cube roots. I'd guess that when Maxima tries to solve the linear equations for the eigenvectors, there are huge expressions that simplify to zero, but Maxima doesn't recognize them as zero. The calculation goes downhill from here. With no symbolic entries, Maxima has no trouble with the eigenvectors; (D16) MATRIX([1,2,3],[4,5,6],[7,8,9]) (C17) eigenvectors(%); Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908650&group_id=4933 
From: SourceForge.net <noreply@so...>  20040304 19:30:11

Bugs item #623681, was opened at 20021015 14:37 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=623681&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratnump(taylor(1,x,0,1)) => true Initial Comment: tay: taylor(1,x,0,1) => 1+... or tay: taylor(x^5,x,0,1) => 1+... ratnump(tay) => true numberp(tay) => true Since taylor series represent approximations, I don't think it's correct to characterize 1+... as a number. The fix is simple: (DEFMFUN $RATNUMP (X) (OR (INTEGERP X) (RATNUMP X) (AND ($RATP X) (not (memq 'trunc (cdar x))) (INTEGERP (CADR X)) (INTEGERP (CDDR X))))) Similarly for Integerp: (DEFMFUN $INTEGERP (X) (OR (INTEGERP X) (AND ($RATP X) (not (memq 'trunc (cdar x))) (INTEGERP (CADR X)) (EQUAL (CDDR X) 1))))  >Comment By: Stavros Macrakis (macrakis) Date: 20040304 14:16 Message: Logged In: YES user_id=588346 I notice that Taylor uses $ratnump internally. These cases will have to be looked at to see if the change causes problems.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=623681&group_id=4933 
From: SourceForge.net <noreply@so...>  20040304 19:20:32

Bugs item #910008, was opened at 20040304 14:06 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=910008&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Combining Taylor series of different orders Initial Comment: taylor(exp(x),x,0,2)  taylor(exp(x),x,0,0) => x + x^2/2 + ... This is wrong. The result should be 0+... (order 0). taylor(exp(x),x,0,2)  taylor(exp(x),x,0,1) => 0 + ... taylor(exp(x),x,0,2) * taylor(exp(x),x,0,5) => 1 + 2*x + 2*x^2 + ... This time, the printed results are correct: the expansion is only as good as the longest of the component expansions. But taylorinfo of the result is [[x,0,2]], that is, taylor thinks that it is 0 + 0*x + 0*x^2 + ... taylor(taylor(exp(x),x,0,2),x,0,5) => 1 + x + x^2/2 + ... This is correct, and the taylorinfo is correctly [[x,0,2]], but shouldn't it give a warning? taylor(x^2,x,0,1)/x politely gives a warning ("0+... assumed to be zero in Taylor"), but the result has taylorinfo [[x,0,2]]. Shouldn't it have taylorinfo [[x,0,1]]? s  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=910008&group_id=4933 
From: SourceForge.net <noreply@so...>  20040304 18:27:59

Bugs item #908650, was opened at 20040302 17:47 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908650&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: eigenvectors() wipes out on 3x3 Initial Comment: Maxima version: 5.9.0.1cvs Maxima build date: 1:57 2/8/2004 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.32 (20031229) (built 3285189666) (memory 3285212279) eigenvectors(m1) just chews CPU on this matrix: (C4) m1 : matrix([a,b,c],[d,e,f],[g,h,0]); on the following it fails with a message (C5) m1 : matrix([k1,k2,k3],[k1,k2,k4],[k3,k4,0]); [  k1 k2  k3 ] [ ] (D5) [ k1  k2  k4 ] [ ] [ k3 k4 0 ] (C6) eigenvectors(m1); Quotient by a polynomial of higher degree #0: EIGENVECTORS(mat=MATRIX([k1,k2,k3],[k1,k2,k4],[k3,k4,0]))(eigen.mac line 122)  an error. Quitting. To debug this try DEBUGMODE(TRUE);)  >Comment By: Barton Willis (willisbl) Date: 20040304 12:13 Message: Logged In: YES user_id=895922 Maxima finds the eigenvalues okay  they are huge ugly expressions with nested square roots and cube roots. I'd guess that when Maxima tries to solve the linear equations for the eigenvectors, there are huge expressions that simplify to zero, but Maxima doesn't recognize them as zero. The calculation goes downhill from here. With no symbolic entries, Maxima has no trouble with the eigenvectors; (D16) MATRIX([1,2,3],[4,5,6],[7,8,9]) (C17) eigenvectors(%); Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908650&group_id=4933 
From: SourceForge.net <noreply@so...>  20040303 00:00:45

Bugs item #908650, was opened at 20040302 17:47 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=908650&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: eigenvectors() wipes out on 3x3 Initial Comment: Maxima version: 5.9.0.1cvs Maxima build date: 1:57 2/8/2004 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.32 (20031229) (built 3285189666) (memory 3285212279) eigenvectors(m1) just chews CPU on this matrix: (C4) m1 : matrix([a,b,c],[d,e,f],[g,h,0]); on the following it fails with a message (C5) m1 : matrix([k1,k2,k3],[k1,k2,k4],[k3,k4,0]); [  k1 k2  k3 ] [ ] (D5) [ k1  k2  k4 ] [ ] [ k3 k4 0 ] (C6) eigenvectors(m1); Quotient by a polynomial of higher degree #0: EIGENVECTORS(mat=MATRIX([k1,k2,k3],[k1,k2,k4],[k3,k4,0]))(eigen.mac line 122)  an error. Quitting. To debug this try DEBUGMODE(TRUE);)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908650&group_id=4933 
From: SourceForge.net <noreply@so...>  20040302 09:51:53

Bugs item #908185, was opened at 20040302 09:33 Message generated for change (Settings changed) made by karstentrulsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908185&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karsten Trulsen (karstentrulsen) >Assigned to: Raymond Toy (rtoy) Summary: wrong derivative of elliptic_e in src/ellipt.lisp Initial Comment: The file src/ellipt.lisp has an incorrect definition of the derivative of the function elliptic_e(u,m) with respect to its first argument. The following output from diff (diff c) applied to the file maxima20040219/src/ellipt.lisp probably fixes the error: *** maxima20040219/src/ellipt.lisp 20030318 02:58:40.000000000 +0100  maxima20040219new/src/ellipt.lisp 20040302 09:54:04.000000000 +0100 *************** *** 1421,1428 **** (defprop $elliptic_e ((phi m) ! ;; (1m*sin(phi)^2) ! ((mplus simp) 1 ((mtimes simp) 1 m ((mexpt simp) ((%sin simp) phi) 2))) ;; diff wrt m ((mtimes simp) ((rat simp) 1 2) ((mexpt simp) m 1) ((mplus simp) (($elliptic_e simp) phi m)  1421,1431  (defprop $elliptic_e ((phi m) ! ;; diff wrt phi ! ;; sqrt(1m*sin(phi)^2) ! ((mexpt simp) ! ((mplus simp) 1 ((mtimes simp) 1 m ((mexpt simp) ((%sin simp) phi) 2))) ! ((rat simp) 1 2)) ;; diff wrt m ((mtimes simp) ((rat simp) 1 2) ((mexpt simp) m 1) ((mplus simp) (($elliptic_e simp) phi m)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908185&group_id=4933 
From: SourceForge.net <noreply@so...>  20040302 09:45:56

Bugs item #908185, was opened at 20040302 09: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=908185&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karsten Trulsen (karstentrulsen) Assigned to: Nobody/Anonymous (nobody) Summary: wrong derivative of elliptic_e in src/ellipt.lisp Initial Comment: The file src/ellipt.lisp has an incorrect definition of the derivative of the function elliptic_e(u,m) with respect to its first argument. The following output from diff (diff c) applied to the file maxima20040219/src/ellipt.lisp probably fixes the error: *** maxima20040219/src/ellipt.lisp 20030318 02:58:40.000000000 +0100  maxima20040219new/src/ellipt.lisp 20040302 09:54:04.000000000 +0100 *************** *** 1421,1428 **** (defprop $elliptic_e ((phi m) ! ;; (1m*sin(phi)^2) ! ((mplus simp) 1 ((mtimes simp) 1 m ((mexpt simp) ((%sin simp) phi) 2))) ;; diff wrt m ((mtimes simp) ((rat simp) 1 2) ((mexpt simp) m 1) ((mplus simp) (($elliptic_e simp) phi m)  1421,1431  (defprop $elliptic_e ((phi m) ! ;; diff wrt phi ! ;; sqrt(1m*sin(phi)^2) ! ((mexpt simp) ! ((mplus simp) 1 ((mtimes simp) 1 m ((mexpt simp) ((%sin simp) phi) 2))) ! ((rat simp) 1 2)) ;; diff wrt m ((mtimes simp) ((rat simp) 1 2) ((mexpt simp) m 1) ((mplus simp) (($elliptic_e simp) phi m)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=908185&group_id=4933 