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}
(20) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(2) 
2

3
(1) 
4

5
(2) 
6
(3) 
7
(3) 
8

9
(7) 
10
(5) 
11
(3) 
12
(2) 
13
(8) 
14
(10) 
15
(1) 
16
(12) 
17
(4) 
18
(14) 
19
(9) 
20
(1) 
21
(10) 
22
(5) 
23
(3) 
24
(2) 
25
(8) 
26
(6) 
27

28
(5) 
29
(2) 
30
(3) 
31
(10) 



From: SourceForge.net <noreply@so...>  20070126 04:43:20

Bugs item #846078, was opened at 20031120 14:02 Message generated for change (Comment added) made by willisbl 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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No 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: Barton Willis (willisbl) Date: 20070125 22:43 Message: Logged In: YES user_id=895922 Originator: YES Fixed by CVS r 1.5. Closing  Comment By: Robert Dodier (robert_dodier) Date: 20060713 01: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...>  20070125 22:19:41

Bugs item #1642851, was opened at 20070123 13:43 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1642851&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: Includes proposed fix >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: notequal isn't negation of equal Initial Comment: The user documentation for 'notequal' says that notequal(a,b) is the negation of equal(a,b). It's not: (%i1) is(equal(x,%i)); (%o1) false (%i2) is(notequal(x,%i)); A putative fix is (defun mnqp (x y) (let ((b (meqp x y))) (cond ((eq b '$unknown) b) ((or (eq b t) (eq b nil)) (not b)) (t `(($notequal) ,x ,y))))) With the exception of test in rtest_taylor 117, this change is OK with the testsuite taylor(atan(1/sqrt(1b))/sqrt(1b),b,1,2) With the proposed mneq code, test 117 asks for the sign of b. If you answer pos (or neg), you get a sign called on %i error. And it seems that the asksign keeps some data about b (it shouldn't). With the old mnqp code, test 117 fails with the sign called on %i error, but it doesn't go thru asksign. Advice?  >Comment By: Barton Willis (willisbl) Date: 20070125 16:19 Message: Logged In: YES user_id=895922 Originator: NO I see that in my initial post, I didn't include the (%o2); it should be "`sign' called on an imaginary argument ..." I applied the suggested fix; previously I commented out test 117 in rtest_taylor.  Comment By: Barton Willis (willisbl) Date: 20070123 13:45 Message: Logged In: YES user_id=895922 Originator: NO I forgot to log in...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1642851&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 22:08:26

Bugs item #1644590, was opened at 20070125 10:38 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644590&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: is equal and kron_delta are inconsistent Initial Comment: Consider: (%i1) is(equal([x],[%i])); (%o1) false (%i2) kron_delta([x],[%i]); (%o2) kron_delta([%i],[x]) kron_delta should simply use the meqp code; something like (defun simpkron_delta (x y z) (twoargcheck x) (setq y (mapcar #'(lambda (s) (simplifya s z)) (margs x))) (let ((p (nth 0 y)) (q (nth 1 y)) (sgn)) (let ((sgn (meqp p q))) (cond ((eq sgn t) 1) ((eq sgn nil) 0) (t `(($kron_delta simp) ,p ,q))))))  >Comment By: Barton Willis (willisbl) Date: 20070125 16:08 Message: Logged In: YES user_id=895922 Originator: YES Applied suggested fix (CVS revision 1.20). Closing bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644590&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 16:38:42

Bugs item #1644590, was opened at 20070125 10:38 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=1644590&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: Includes proposed fix Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: is equal and kron_delta are inconsistent Initial Comment: Consider: (%i1) is(equal([x],[%i])); (%o1) false (%i2) kron_delta([x],[%i]); (%o2) kron_delta([%i],[x]) kron_delta should simply use the meqp code; something like (defun simpkron_delta (x y z) (twoargcheck x) (setq y (mapcar #'(lambda (s) (simplifya s z)) (margs x))) (let ((p (nth 0 y)) (q (nth 1 y)) (sgn)) (let ((sgn (meqp p q))) (cond ((eq sgn t) 1) ((eq sgn nil) 0) (t `(($kron_delta simp) ,p ,q))))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644590&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 16:33:13

Bugs item #1644582, was opened at 20070125 11: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=1644582&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: acos(1d200) causes overflow Initial Comment: acos(1d200) causes an overflow. However, Lisp (cmucl) says (cl:acos 1d200) is #C(0.0 461.2101657793691) The implementation of maximabranchasin needs some work not to overflow unnecessarily. I think maximabranchacos suffers from roundoff for x = 1+eps.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644582&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 16:21:18

Bugs item #1644575, was opened at 20070125 11: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=1644575&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: acot(0.0) vs acot(0) Initial Comment: acot(0) > %pi/2. Ok acot(0.0) > domain error. Is that expected? I would have expected acot(0.0) > 1.57.... But limit(acot(x),x,0,'minus) > %pi/2. What do we want?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644575&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 15:47:33

Bugs item #1634789, was opened at 20070113 10:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1634789&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: Problem not in Maxima Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Tensor indices display question Initial Comment: OK, not sure how but the help manual says that when tensors are shown they have the upstairs indicies above the downstairs ones, like the delta tensor, eg. i G jmn but what i observe is that the indicies are like soin wxMaxima0.7.1 i G jmn not sure if that is dealt with already in the documentation but this is what i came across Maxima version: 5.10.99rc2Maxima build date: 19:23 12/13/2006host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8 all the best harry.georgiou@...  >Comment By: Robert Dodier (robert_dodier) Date: 20070125 08:47 Message: Logged In: YES user_id=501686 Originator: NO After corresponding with Harry, Andrej Vodopivec, and Viktor Toth, I've concluded the display problem is in wxMaxima. Closing this report accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20070113 21:36 Message: Logged In: YES user_id=501686 Originator: NO It looks to me like the problem, if any, is in wxMaxima. I'll write to harry.georgiou@... to try to clarify.  Comment By: Nobody/Anonymous (nobody) Date: 20070113 11:06 Message: Logged In: NO ok for some reason it did not display what i wanted here is another go G^(i)_(jkl) in the documentation i is above j but in the wxmaxima it is upstairs where it should be but after l. in Xmaxima it does not seem to have this problem with the positioning of indicies all the best  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1634789&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 13:33:55

Bugs item #1644378, was opened at 20070125 06:48 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644378&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 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: floor and ceiling change bigfloatone Initial Comment: Look at bigfloatone: (%i1) ?print(?bigfloatone); ((BIGFLOAT SIMP 56) 36028797018963968 1) Compute a ceiling of a constant: (%i2) ceiling(log(1.3b0)/log(2)); (%o2) 1 Look at bigfloatone: Yikes! It changed (%i3) ?print(?bigfloatone); ((BIGFLOAT SIMP 218) <junk>) Now compute log(2.0b0) (%i4) log(2.0b0); (%o4) 6.9314718055[lots of digits] 0095b1 But fpprec is still the default. (%i5) fpprec; (%o5) 16  >Comment By: Barton Willis (willisbl) Date: 20070125 07:33 Message: Logged In: YES user_id=895922 Originator: YES I think maxmin.lisp needs function something like (defun protectedbigfloat (e n) (unwindprotect (progn (fpprec1 '$fpprec n) (simplify ($bfloat e))) (fpprec1 '$fpprec $fpprec))) Comments?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644378&group_id=4933 
From: SourceForge.net <noreply@so...>  20070125 12:48:26

Bugs item #1644378, was opened at 20070125 06:48 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=1644378&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 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: floor and ceiling change bigfloatone Initial Comment: Look at bigfloatone: (%i1) ?print(?bigfloatone); ((BIGFLOAT SIMP 56) 36028797018963968 1) Compute a ceiling of a constant: (%i2) ceiling(log(1.3b0)/log(2)); (%o2) 1 Look at bigfloatone: Yikes! It changed (%i3) ?print(?bigfloatone); ((BIGFLOAT SIMP 218) <junk>) Now compute log(2.0b0) (%i4) log(2.0b0); (%o4) 6.9314718055[lots of digits] 0095b1 But fpprec is still the default. (%i5) fpprec; (%o5) 16  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1644378&group_id=4933 
From: Esdras Weston <maxwey@ja...>  20070124 21:46:35

Good day, VlAG_GRA $1, 80 ClAL_LIS $3, 00 LEVl_ITRA $3, 35 http://www.rabietichb*com ( Important! Replace * with . )  her front teeth was more noticeable than ever; Harry couldnt understand how he hadnt spotted it before. Hi, Harry! she said. Hi, Parvati! 
From: SourceForge.net <noreply@so...>  20070124 13:05:22

Bugs item #1643519, was opened at 20070124 05:05 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=1643519&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: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima Help on Windows XP prevents access to xmaxima 5.11.0 Initial Comment: When the HTML Help is launched on xmaxima 5.11.0, by choosing "Maxima Manual" on the "Help" menu, it is not possible to go back to the xmaxima window. Only after closing the HTML Help window one can gain access to the xmaxima window again.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1643519&group_id=4933 
From: SourceForge.net <noreply@so...>  20070123 19:45:29

Bugs item #1642851, was opened at 20070123 13:43 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1642851&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: notequal isn't negation of equal Initial Comment: The user documentation for 'notequal' says that notequal(a,b) is the negation of equal(a,b). It's not: (%i1) is(equal(x,%i)); (%o1) false (%i2) is(notequal(x,%i)); A putative fix is (defun mnqp (x y) (let ((b (meqp x y))) (cond ((eq b '$unknown) b) ((or (eq b t) (eq b nil)) (not b)) (t `(($notequal) ,x ,y))))) With the exception of test in rtest_taylor 117, this change is OK with the testsuite taylor(atan(1/sqrt(1b))/sqrt(1b),b,1,2) With the proposed mneq code, test 117 asks for the sign of b. If you answer pos (or neg), you get a sign called on %i error. And it seems that the asksign keeps some data about b (it shouldn't). With the old mnqp code, test 117 fails with the sign called on %i error, but it doesn't go thru asksign. Advice?  >Comment By: Barton Willis (willisbl) Date: 20070123 13:45 Message: Logged In: YES user_id=895922 Originator: NO I forgot to log in...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1642851&group_id=4933 
From: SourceForge.net <noreply@so...>  20070123 19:43:42

Bugs item #1642851, was opened at 20070123 11:43 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=1642851&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: notequal isn't negation of equal Initial Comment: The user documentation for 'notequal' says that notequal(a,b) is the negation of equal(a,b). It's not: (%i1) is(equal(x,%i)); (%o1) false (%i2) is(notequal(x,%i)); A putative fix is (defun mnqp (x y) (let ((b (meqp x y))) (cond ((eq b '$unknown) b) ((or (eq b t) (eq b nil)) (not b)) (t `(($notequal) ,x ,y))))) With the exception of test in rtest_taylor 117, this change is OK with the testsuite taylor(atan(1/sqrt(1b))/sqrt(1b),b,1,2) With the proposed mneq code, test 117 asks for the sign of b. If you answer pos (or neg), you get a sign called on %i error. And it seems that the asksign keeps some data about b (it shouldn't). With the old mnqp code, test 117 fails with the sign called on %i error, but it doesn't go thru asksign. Advice?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1642851&group_id=4933 
From: Gaila Leflore <atona@ma...>  20070123 19:16:06

Good day, VlA_AGRA $1, 80 ClA_ALIS $3, 00 LEV_VlTRA $3, 35 http://www.printeryml*com ( Important ! Replace "*" with "." )  a good, hard training session. On the other hand, their lessons were becoming more difficult and demanding than ever before, particularly Moodys Defense Against the Dark Arts. 
From: SourceForge.net <noreply@so...>  20070122 11:50:08

Bugs item #709138, was opened at 20030324 19:12 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=709138&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor 0/0 internal error Initial Comment: taylor(x^3,x,0,2)/taylor(x^3,x,0,2) => Error: Caught fatal error [memory may be damaged] This is of course a real user error (0/0)  so should have a USER error message, not an internal fatal error. It may be possible to do something more useful than an error, but in the meantime, a clean error would be good. Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Barton Willis (willisbl) Date: 20070122 05:50 Message: Logged In: YES user_id=895922 Originator: NO I think this bug has been fixed: (%i1) taylor(x^3,x,0,2)/taylor(x^3,x,0,2); `taylor': `taylordepth' exceeded while expanding: (0+...)^(1)  an error. Quitting. To debug this try debugmode(true); (%i5) 1/taylor(0,x,0,3); `taylor': `taylordepth' exceeded while expanding: (0+...)^(1)  an error. Quitting. To debug this try debugmode(true);  Comment By: Stavros Macrakis (macrakis) Date: 20030324 19:13 Message: Logged In: YES user_id=588346 Also 1/taylor(0,x,0,3);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=709138&group_id=4933 
From: SourceForge.net <noreply@so...>  20070122 11:06:33

Bugs item #1641498, was opened at 20070122 05: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=1641498&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 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Function "at" is overly cautious Initial Comment: Compare (%i1) at(f(x), x = 0); (%o1) f(0) with (%i2) at('integrate(f(t),t,0,x),x=0); (%o2) at(integrate(f(t),t,0,x),x=0) Given (%o1), it would seem consistent for (%o2) to evaluate to 0. Declaring f to be anaylic doesn't help: (%i3) declare(f,analytic); (%o3) done (%i4) at('integrate(f(t),t,0,x),x=0); (%o4) at(integrate(f(t),t,0,x),x=0) Does Maxima ever use the declare analytic data?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641498&group_id=4933 
From: SourceForge.net <noreply@so...>  20070122 10:58:32

Bugs item #1641474, was opened at 20070122 04:43 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=1641474&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor polynomials of polylogs Initial Comment: (%i4) taylor(li[7](x),x,0,4); `taylor' encountered an unfamiliar singularity in: A correct answer is x + ((x^2)/128) + ((x^3)/2187) + ((x^4)/16384) + . . . An easy fix is to append a deftaylor for li. But deftaylor has its own problems: (%i1) deftaylor(li[s](x), sum(x^k/k^s,k,1,inf))$ (%i2) taylor(li[3](x),x,0,2); (%o2) x+x^2/8+... (%i3) taylor(li[3](x),x,1,2); `taylor' unable to expand at a point specified in: sum(x^*index/*index^s,*index,1,inf)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641474&group_id=4933 
From: SourceForge.net <noreply@so...>  20070122 10:52:05

Bugs item #1641487, was opened at 20070122 04:51 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=1641487&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: deftaylor Initial Comment: deftaylor works OK for expansion at zero, but don't try to expand anywhere else: (%i1) deftaylor(f(x), sum(x^k,k,0,inf)); (%o1) [f] (%i2) taylor(f(x),x,0,2); (%o2) 1+x+x^2+... (%i3) taylor(f(x),x,1,2); `taylor' unable to expand at a point specified in: sum(x^*index,*index,0,inf)  an error. Quitting. To debug this try debugmode(true); Notice the garabage in the error message. For an expansion at a nonzero number, it would be better if Maxima used the differentiate and evaluate scheme instead of trying to use the deftaylor info.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641487&group_id=4933 
From: SourceForge.net <noreply@so...>  20070122 10:36:12

Bugs item #1641457, was opened at 20070122 04:36 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=1641457&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor polynomials of Bessel functions Initial Comment: Bessel_j(0,x) is analytic at 0 yet (%i1) taylor(bessel_j(0,x),x,0,2); `taylor' encountered an unfamiliar singularity in: Taylor has no problem expanding bessel_j at 1: (%i2) taylor(bessel_j(0,x),x,1,2); (%o2) < junk deleted> I think the problem with the expansion at zero is the derivative of bessel_j(0,x) is (%i3) diff(bessel_j(0,x),x,2); (%o3) bessel_j(1,x)/xbessel_j(0,x) Trying to evaluate this at zero causes problems.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641457&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 22:10:16

Bugs item #1639678, was opened at 20070119 11:18 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639678&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: 6 Private: No Submitted By: Kirill Smelkov (kirr) Assigned to: Nobody/Anonymous (nobody) Summary: 3*sqrt(2)/sqrt(3)/sqrt(6) != 1 Initial Comment: Maxima can't simplify this to 1:: (%i1) 3*sqrt(2)/sqrt(3)/sqrt(6); 3 sqrt(2) (%o1)  sqrt(3) sqrt(6)  (%i2) %^2; (%o2) 1 (%i3) build_info(); Maxima version: 5.11.0cvs Maxima build date: 19:58 1/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6  >Comment By: Stavros Macrakis (macrakis) Date: 20070121 17:10 Message: Logged In: YES user_id=588346 Originator: NO I count it as a bug, and a serious one. Radcan shouldn't be necessary for simple cases like this.  Comment By: Kirill Smelkov (kirr) Date: 20070121 05:09 Message: Logged In: YES user_id=834496 Originator: YES So is this a bug or one should always use radcan?  Comment By: Raymond Toy (rtoy) Date: 20070119 12:47 Message: Logged In: YES user_id=28849 Originator: NO radcan(%o1) > 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639678&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 22:06:23

Bugs item #1641062, was opened at 20070121 17:05 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641062&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  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit allows nonsymbol variable and gives nonsense results Initial Comment: Limit should presumably only accept variable names (symbols and subscripted symbols) as its second argument. It currently doesn't check, and gives nonsense results with nonvariablename arguments: limit(1/x,1/x,inf) => inf (OK, why not? but see examples below) limit(x,x^3,inf) => x (NO, should be inf if anything) limit(x,1/x,inf) => x (NO, should be 0 if anything) limit(sin(x),x*y,inf) => sin(x) (???) limit(x^2+2,x^22,3) => x^2+2 (I suppose this ought to be 7) Sometimes, unsurprisingly, it gets internal errors: limit(x,sin(x),inf); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ($X) Maxima 5.11.0 GCL 2.6.8 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641062&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 22:05:11

Bugs item #1641062, was opened at 20070121 17:05 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=1641062&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit allows nonsymbol variable and gives nonsense results Initial Comment: Limit should presumably only accept variable names (symbols and subscripted symbols) as its second argument. It currently doesn't check, and gives nonsense results with nonvariablename arguments: limit(1/x,1/x,inf) => inf (OK, why not? but see examples below) limit(x,x^3,inf) => x (NO, should be inf if anything) limit(x,1/x,inf) => x (NO, should be 0 if anything) limit(sin(x),x*y,inf) => sin(x) (???) limit(x^2+2,x^22,3) => x^2+2 (I suppose this ought to be 7) Sometimes, unsurprisingly, it gets internal errors: limit(x,sin(x),inf); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ($X) Maxima 5.11.0 GCL 2.6.8 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1641062&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 20:32:07

Bugs item #817516, was opened at 20031003 21:27 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817516&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  Taylor Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(xxx)xxx incorrect Initial Comment: Define q: q:(LOG(n)n)/(LOG(n)1)$ Get a series representation around infinity to 1 term: qt: taylor(q,n,inf,1); ((1/LOG(n))+...)*n+(1+1/LOG(n)+...)+... OK so far. Now take the difference of the original q and the series: qdiff: qqt; (11/LOG(n)1/LOG(n)^21/LOG(n)^3 1/LOG(n)^4+...) * n + (1+1/LOG(n)+...)+... taylorinfo(qt) => [[1/LOG(n),ZEROA,1],[n,INF,1]] taylorinfo(qdiff) => [[1/LOG(n),ZEROA,4],[n,INF,4]] The result should have been the same as: qdiffr: taylor(qratsimp(qt),n,inf,1) which gives (almost correctly, cf bug #774065) ZEROA*N + (ZEROA * LOG(N)  ZEROA + ...) +... i.e. 0+... Huh? First of all, the answer is not correct. The initial terms should have cancelled. Secondly, why did it calculate three more terms?  >Comment By: Stavros Macrakis (macrakis) Date: 20070121 15:32 Message: Logged In: YES user_id=588346 Originator: YES Actually, this now works in Maxima 5.11.0 GCL 2.6.8 W2k Athlon, but you need to enter the log function in lower case: q:(log(n)n)/(log(n)1)$ Closing as fixed. s  Comment By: Barton Willis (willisbl) Date: 20070121 14:41 Message: Logged In: YES user_id=895922 Originator: NO With Maxima 5.11, I get (%i1) q:(LOG(n)n)/(LOG(n)1); (%o1) (LOG(n)n)/(LOG(n)1) (%i2) qt: taylor(q,n,'inf,1); `taylor' encountered an unfamiliar singularity in: LOG(n)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817516&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 20:26:26

Bugs item #769860, was opened at 20030711 16:49 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&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  Taylor Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor bind stack overflow: sin(2*atan(x))@q Initial Comment: taylor(sin(2*atan(x)),x,q,1) results in a bind stack overflow (internal error)  try expand appears to be in an infinite recursion. The expansion is wellbehaved, and can be derived using the TaylorMacLaurin formula: r1: taylor(f(x),x,q,1)$ r2: subst(lambda([x],sin(2*atan(x))),f,r1)$ r3: ev(r2,diff,at)$ Which gives: 2 COS(2 ATAN(q)) (x  q)  + SIN(2 ATAN(q)) 2 q + 1 This can be prettified: map(factor,trigexpand(r3)) ...=> 2 q 2 (q  1) (q + 1) (x  q)    2 2 2 q + 1 (q + 1)  >Comment By: Stavros Macrakis (macrakis) Date: 20070121 15:26 Message: Logged In: YES user_id=588346 Originator: YES Now works in my Maxima 5.11.0 GCL 2.6.8 W2k Athlon Thanks for testing, Barton. Closing. s  Comment By: Barton Willis (willisbl) Date: 20070121 15:14 Message: Logged In: YES user_id=895922 Originator: NO I don't get a bind stack overflow (5.11, 2.6.8 GCL) (%i1) taylor(sin(2*atan(x)),x,q,1); (%o1) sinh(log(sqrt(q^2+1)*%e^(%i*atan(q)))log(sqrt(q^2+1)*%e^(%i*atan(q))))*%i+(2*cosh(log(sqrt(q^2+1)*%e^(%i*atan(q)))log(sqrt(q^2+1)*%e^(%i*atan(q))))*(xq))/(q^2+1)+... (%i2) map(rectform,%); (%o2) (2*cos(2*atan(q))*(xq))/(q^2+1)+sin(2*atan(q))  Comment By: Stavros Macrakis (macrakis) Date: 20030711 20:46 Message: Logged In: YES user_id=588346 Untabified: 2 COS(2 ATAN(q)) (x  q)  + SIN(2 ATAN(q)) 2 q + 1 map(factor,trigexpand(r3)); 2 q 2 (q  1) (q + 1) (x  q)    2 2 2 q + 1 (q + 1)  Comment By: Stavros Macrakis (macrakis) Date: 20030711 20:44 Message: Logged In: YES user_id=588346 Did I forget to untabify? Or is sourceforge compressing spaces now? Testing: aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 20:23:49

Bugs item #629539, was opened at 20021027 14:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629539&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(x + sqrt(1+x^2),x,a,2) Initial Comment: (C1) display2d : false; (D1) FALSE (C2) p : x + sqrt(1+x^2); (D2) SQRT(x^2+1)+x With ratfac true, Maxima finds the Taylor polynomial of p centered at a with no problem (C3) ratfac : true; (D3) TRUE (C4) taylor(p,x,a,2); (D4) SQRT(a^2+1)+a+(a^2+SQRT(a^2+1)*a+1)*(xa)/(a^2+1) +(xa)^2/(2*SQRT(a^2+1)*(a^2+1)) But setting ratfac to false, we get an error (C5) ratfac : false; (D5) FALSE (C6) taylor(p,x,a,2); Quotient by a polynomial of higher degree  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C7) This same bug may be responsible for the bug (C11) taylor(asin(x),x,a,2), ratfac : false; Quotient by a polynomial of higher degree  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C12) taylor(asin(x),x,a,2), ratfac : true; Is (a1)*(a+1) positive, negative, or zero? neg; (D12) ATAN2(a,SQRT(1a^2))(a^2+SQRT(a^21)*a1)*%I*(xa) /((a+SQRT(a^21))*(a^21)) +(2*a^3+2*SQRT(a^21)*a^22*aSQRT(a^21))*%I*a *(xa)^2 /(2*(a+SQRT(a^21))^2*(a^21)^2) (C13)  >Comment By: Barton Willis (willisbl) Date: 20070121 14:23 Message: Logged In: YES user_id=895922 Originator: NO setting gcd : spmod "fixes" this bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629539&group_id=4933 