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
(1) 
3
(1) 
4

5
(1) 
6
(4) 
7
(1) 
8

9
(1) 
10

11

12
(5) 
13
(5) 
14

15

16
(3) 
17
(1) 
18
(4) 
19
(2) 
20
(2) 
21

22

23
(2) 
24
(1) 
25
(7) 
26

27

28
(4) 
29

30
(1) 
31

From: SourceForge.net <noreply@so...>  20030530 00:28:45

Bugs item #745842, was opened at 20030529 17:28 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=745842&group_id=4933 Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ctensr problems Initial Comment: There seem to be a couple of problems in ctensr: 1) A minor documentation issue; contrary to the docs, you have to do load(ctensr); before tsetup(); 2) A more serious problem: at some point it fails to print a prompt, although if you know what to type and keep going, it accepts the input, as shown here: (C1) tsetup(); (D1) TSETUP() (C2) load(ctensr); (D2) /usr/share/maxima/5.9.0/share/tensor/ctensr.mac (C3) tsetup(); enter the dimension of the coordinate system: 4; do you wish to change the coordinate names? n; do you want to 1. enter a new metric? 2. enter a metric from a file? 3. approximate a metric with a taylor series? 1; Is the matrix 1. Diagonal 2. Symmetric 3. Antisymmetric 4. General 1; a^2; a^2; a^2; 1; Answer 1, 2, 3 or 4 : Row 1 Column 1: Row 2 Column 2: Row 3 Column 3: Row 4 Column 4: Matrix entered. enter functional dependencies with the depends function or 'n' if none depends(a,t); do you wish to see the metric? y; [ 2 ] [ a 0 0 0 ] [ ] [ 2 ] [ 0 a 0 0 ] [ ] [ 2 ] [ 0 0 a 0 ] [ ] [ 0 0 0  1 ] do you wish to see the metric inverse? n; (D3) DONE (C4) 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.0 Maxima build date: 21:17 2/9/2003 host type: i386redhatlinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18d Notice that it printed the prompts only after all the metric components had been typed. In xmaxima, the problem is worse, and the prompts stop immediately. Larry Ford ford@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=745842&group_id=4933 
From: SourceForge.net <noreply@so...>  20030528 17:03:01

Bugs item #727542, was opened at 20030425 11:35 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727542&group_id=4933 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: powerseries wrong/fix Initial Comment: (C51) gf:2*(1751144*x4882*x^3+4324*x^42072*x^5+416*x^6+3189*x^2)/ (2*x1)^3/(4*x1)/(x1)^3$ (C52) taylor(gf,x,0,3); 2 3 (D52)/T/ 350 + 2262 x + 11634 x + 53650 x + . . . (C53) taylor(powerseries(gf,x,0),x,0,3); 2 3 (D53)/T/ 470 + 2862 x + 13524 x + 58750 x + . . . maybe this is related to sum(x^i,i,0,inf),x:0 giving 0, but I don't know... I checked D53 with Maple, so it seems that powerseries is wrong, not taylor. I converted the result of powerseries to the rational function again, and obtained: 2*(9407436*x41588*x^322066*x^5+40253*x^4+416*x^81816*x^7+7076*x^6+24227*x^2) /(2*x1)^3/(4*x1)/(x2)^2/(x1)^3 The difference between the two is 160*'SUM((I+1)*2^I*x^I,I,0,INF)160*'SUM((I+1)*2^(I2)*x^I,I,0,INF) so the reason might be a simple typo ( instead of + or the like)... Should be possible to correct this... Martin  >Comment By: Raymond Toy (rtoy) Date: 20030528 13:03 Message: Logged In: YES user_id=28849 Patch applied.  Comment By: Martin Rubey (kratt5) Date: 20030430 13:35 Message: Logged In: YES user_id=651552 Here is the fix. It's a typo, as I expected... should really be applied as soon as possible since it gets everything wrong, where the partial fraction expansion contains (a*x+c)^(2)... Martin diff c series.lisp series.lisp.~1.1.1.1.~ *** series.lisp Wed Apr 30 19:32:58 2003  series.lisp.~1.1.1.1.~ Mon May 8 08:09:41 2000 *************** *** 248,255 **** 0)) ((= 2 n) (psp2form (m* (m+ 1 *index) ! (m^ a (m* 1 (m+ 2 *index))) ;; kratt5 ! (m^ (m* 1 c) *index)) ;; kratt5 (if (equal m 1) *index (m* *index m)) 0)) (t (psp2form (m* (do ((nn (f1 n) (f1 nn))  248,255  0)) ((= 2 n) (psp2form (m* (m+ 1 *index) ! (m^ c (m* 1 (m+ 2 *index))) ! (m^ (m* 1 a) *index)) (if (equal m 1) *index (m* *index m)) 0)) (t (psp2form (m* (do ((nn (f1 n) (f1 nn))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727542&group_id=4933 
From: SourceForge.net <noreply@so...>  20030528 16:41:10

Bugs item #738848, was opened at 20030516 12:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 Category: Share Libraries Group: Fix for 5.9.0 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Poverseries error for 1/(1t)^2 Initial Comment: It seems powerseries(1(ab*t)^n, t, 0) produces an error for n=2, but is correct for n=1,3,4: (C1) POWERSERIES(1/(ab*t)^2, t, 0); INF ==== \ I1  I1  2 I1 (D1) > a b (I1 + 1) t / ==== I1 = 0 [I believe that powers of a and b above have opposite signs].  >Comment By: Raymond Toy (rtoy) Date: 20030528 12:41 Message: Logged In: YES user_id=28849 Bug marked as duplicate. I'll apply your patch for bug 727542.  Comment By: Martin Rubey (kratt5) Date: 20030519 04:32 Message: Logged In: YES user_id=651552 This is fixed with the fix for [727542] powerseries wrong/fix Martin (please, somebody merge it into cvs, it is IMPORTANT!)  Comment By: Nobody/Anonymous (nobody) Date: 20030517 14:32 Message: Logged In: NO (C1) verbose:true; (D1) TRUE (C2) POWERSERIES(1/(ab*t)^2, t, 0); In the first simplification we have returned: 1  2 2 2 b t  2 a b t + a trying to do a rational function expansion of 1  2 2 2 b t  2 a b t + a Using a special rule for expressions of form M  N (A + C VAR ) Here we have [N = 2, A =  a, C = b, M = 1] INF ==== \ I1  I1  2 I1 (D2) > a b (I1 + 1) t / ==== I1 = 0 (C3)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 
From: SourceForge.net <noreply@so...>  20030528 16:33:06

Bugs item #744679, was opened at 20030527 22:30 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=744679&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 overflows memory? Initial Comment: expr: (x^(1/n)+1)^n/2^n; limit(expr,n,inf); Is x positive or negative? pos;Is x  1 positive or negative? pos; Error: Contiguous blocks exhausted. Currently, 129 pages are allocated. Use ALLOCATECONTIGUOUSPAGES to expand the space. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at HAIPART. Type :H for Help.  a) Of course it shouldn't cause this sort of error at all. b) What is allocatecontiguouspages??? There is apparently no such function in gcl. By the way, tlimit gets the correct result, sqrt(x). Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030528 12:33 Message: Logged In: YES user_id=28849 With CMUCL, we also get an error. It seems we're trying to compute 2^16384, and CMUCL stops if the exponent is too large. Presumably gcl is trying to compute the same thing and has run out of memory for this number.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=744679&group_id=4933 
From: SourceForge.net <noreply@so...>  20030528 02:30:46

Bugs item #744679, was opened at 20030527 22:30 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=744679&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 overflows memory? Initial Comment: expr: (x^(1/n)+1)^n/2^n; limit(expr,n,inf); Is x positive or negative? pos;Is x  1 positive or negative? pos; Error: Contiguous blocks exhausted. Currently, 129 pages are allocated. Use ALLOCATECONTIGUOUSPAGES to expand the space. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at HAIPART. Type :H for Help.  a) Of course it shouldn't cause this sort of error at all. b) What is allocatecontiguouspages??? There is apparently no such function in gcl. By the way, tlimit gets the correct result, sqrt(x). Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=744679&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 17:43:31

Bugs item #701677, was opened at 20030311 12:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701677&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Raymond Toy (rtoy) Summary: plot2d evaluates outside range Initial Comment: plot2d evaluates the function being plotted outside the given range. Try: f(x):= if (x>1) then 0 else x^2$ plot2d(f,[x,0,1]) The plot shows the function dropping to 0 at x=1+eps. This is bad for three reasons: 1) I explicitly asked for the range [0,1]. I do not want to see the behavior for x>1. 2) I don't want the yrange to be distorted by an outlier at x=1+eps. 3) the function may not be welldefined, and may cause errors, outside the range I gave. (This is how I discovered the issue.) Plot2d also evaluates the function at twice as many values as it uses (to check for smoothness)  I'd think we could do better than that, but maybe not.  >Comment By: Raymond Toy (rtoy) Date: 20030525 13:43 Message: Logged In: YES user_id=28849 Should be fixed now.  Comment By: Raymond Toy (rtoy) Date: 20030403 13:25 Message: Logged In: YES user_id=28849 I agree. This is very annoying. I think the reason is due to round off and the way extra samples are taken. I have a fix for this so we don't go outside the range, and every computed point is used in the plot instead of throwing away half the points. Needs work. I think we should give up on being smart.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701677&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 15:26:35

Bugs item #716059, was opened at 20030405 20:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716059&group_id=4933 Category: Xmaxima Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Someones Dad (someonesdad) Assigned to: Nobody/Anonymous (nobody) Summary: load(ellipt) doesn't work Initial Comment: Under Maxima 5.9.0 on Windows 2000, I get a "Load failed..." message. This also failed on Maxima 5.5. This is referenced in the documentation under the link share/maxima/5.9.0/doc/html/maxima_23.html#SEC74  >Comment By: Raymond Toy (rtoy) Date: 20030525 11:26 Message: Logged In: YES user_id=28849 Documentation should be corrected. The elliptic functions are now included in the core, and are more complete than the version in share/specfunctions/ellipt.lisp. ellipt.lisp should be removed as well.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716059&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 15:24:37

Bugs item #718574, was opened at 20030409 16:43 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=718574&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Bessel_J or %J ??? Maxima not consistent Initial Comment: Maxima appears to use *both* the notation Bessel_J[i] (x) and %J[i](x) to denote the Bessel Jfunction. Bessel_J is used only in the file bessel.lisp, and %J everywhere else (comm, hyp, hypgeo, ode2). Could we unify these? Or is there some reason to keep them separate?  >Comment By: Raymond Toy (rtoy) Date: 20030525 11:24 Message: Logged In: YES user_id=28849 Unify. Per discussions on the mailing list, I think bessel_j is the preferred notation.  Comment By: Raymond Toy (rtoy) Date: 20030414 14:20 Message: Logged In: YES user_id=28849 Don't know the history, but it's been that way for as long as I can remember. I think we should unify them to just one or the other. Bessel_J is better because it's more explicit, but %J is closer to the typical math notation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=718574&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 15:10:43

Bugs item #736540, was opened at 20030512 12:31 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736540&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: gradef for bessel functions Initial Comment: Consider (C1) display2d : false; Evaluation took 0.00 seconds (0.00 elapsed) (D1) FALSE (C2) diff(bessel_j(x,x),x); Evaluation took 0.00 seconds (0.00 elapsed) (D2) 'DIFF(BESSEL_J[x](x),x,1)BESSEL_J[x](x) +BESSEL_J[x1](x) The derivative in the first term of (d2) is should be with respect to the order of the bessel function  instead it's a _total_ derivative. A good solution isn't easy; in orthopoly, I handle this problem by signaling an error. Thus (from orthopoly) ;; When a user requests the derivative of an a function in this package ;; with respect to the order or some other parameter, return a form ;; ((unk) input from user). We "simplify" this form by printing an error. (defprop unk simpunk operators) (defun simpunk (x y z) (declare (ignore y z)) (merror "Maxima doesn't know the derivative of ~:M with respect the ~:M argument" (nth 2 x) (nth 1 x))) (putprop '$legendre_p '((n x) ((unk) "$first" "$legendre_p") ((mtimes) ((mplus) ((mtimes) n (($legendre_p) ((mplus) 1 n) x)) ((mtimes) 1 n (($legendre_p) n x) x)) ((mexpt) ((mplus) 1 ((mtimes) 1 ((mexpt) x 2))) 1))) 'grad) (C3) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Evaluation took 0.00 seconds (0.00 elapsed) (D3) (C4) Barton  >Comment By: Raymond Toy (rtoy) Date: 20030525 11:10 Message: Logged In: YES user_id=28849 Derivative with respect to order added for Bessel J. It's a bit messy.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736540&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 15:01:40

Bugs item #736535, was opened at 20030512 12:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Raymond Toy (rtoy) Summary: half integer bessel_y function Initial Comment: The halfinteger bessel functions of the second kind (the Y functions) evaluate incorrectly. Consider (C1) besselexpand : true; (D1) TRUE (C2) w : bessel_y[1/2](x)$ (C3) display2d : false; (D3) FALSE (C4) ev(w); (D4) SQRT(2)*SIN(x)/(SQRT(%PI)*SQRT(x)) (C5) The sin(x) upstairs should be a cos(x); to fix this, I think we need to swap %sin and %cos in bessselysimp; change the line (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%sin '%cos))) to (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%cos '%sin))) Additionally, the halfinteger bessel functions evaluate to elementary functions too slowly. Consider (D5) ALL (C6) besselexpand : true; Evaluation took 0.00 seconds (0.00 elapsed) (D6) TRUE (C7) w : bessel_j[19/2](x)$ Evaluation took 0.82 seconds (0.82 elapsed) (C8) w : bessel_j[21/2](x)$ Evaluation took 2.47 seconds (2.47 elapsed) (C9) w : bessel_j[23/2](x)$ Evaluation took 43.87 seconds (43.87 elapsed) The time is increasing much too rapidly. Barton  >Comment By: Raymond Toy (rtoy) Date: 20030525 11:01 Message: Logged In: YES user_id=28849 Both of these issues should be fixed. The derivative with respect to order only done for J, though.  Comment By: Raymond Toy (rtoy) Date: 20030512 23:57 Message: Logged In: YES user_id=28849 The slow evaluation of the halfinteger functions is caused by a poor choice of algorithms. It computes a larger order derivative to find the answer. Should use a different algorithm such as the one in A&S 10.1.8 and 10.1.9.  Comment By: Raymond Toy (rtoy) Date: 20030512 23:54 Message: Logged In: YES user_id=28849 The slow evaluation of the halfinteger functions is caused by a poor choice of algorithms. It computes a larger order derivative to find the answer. Should use a different algorithm such as the one in A&S 10.1.8 and 10.1.9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 14:14:39

Bugs item #695086, was opened at 20030228 09:33 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=695086&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d number overflow Initial Comment: plot2d(1.0e9,[x,0,1]) gives the popup error "Error: integer value too large to represent". "Details" shown below. It also doesn't recover well from the error  it shows an empty plot window (in Plot Windows: Separate mode). Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 integer value too large to represent integer value too large to represent while executing "expr {round(ceil($aa)) }" (procedure "getTicks" line 12) invoked from within "getTicks $y2 $y1 [expr {$shei/50}" (procedure "axisTicks" line 27) invoked from within "axisTicks $win $c" (procedure "replot2d" line 40) invoked from within "replot2d $win" (procedure "plot2d" line 4) invoked from within "plot2d data {plot2d {label "1.0E+9"} {xversusy { 0.0000000000 0.0100000000 0.0200000000 0.0300000000 0.0400000000 0.0500000000 0.0600000000 0...." ("eval" body line 1) invoked from within "eval $command" (procedure "doShowPlot" line 14) invoked from within "doShowPlot $win $data" (procedure "maximaFilter" line 45) invoked from within "maximaFilter .maxima.text sock208"  >Comment By: Raymond Toy (rtoy) Date: 20030525 10:14 Message: Logged In: YES user_id=28849 This seems to be an issue with tcl/tk. With gnuplot, a straight line is plotted.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=695086&group_id=4933 
From: SourceForge.net <noreply@so...>  20030525 14:07:32

Bugs item #694770, was opened at 20030227 19:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694770&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Raymond Toy (rtoy) Summary: plot2d stunningly slow in some simple cases Initial Comment: plot2d(x*1.01,[x,0,1]) is fast (16mS). plot2d(x*1.01e2,[x,0,1]) is surprisingly slower (2683mS) plot2d(x*1.01e4,[x,0,1]) is so slow I didn't bother to wait. What is going on here? This is ridiculous! Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  >Comment By: Raymond Toy (rtoy) Date: 20030525 10:07 Message: Logged In: YES user_id=28849 Should be fixed with the adaptive plotting routine  Comment By: Raymond Toy (rtoy) Date: 20030403 13:23 Message: Logged In: YES user_id=28849 This is caused by draw2d. It tries to be smart so that if the dy is larger than dx, a smaller step is taken. For the second example, EVERY dy is too large, so we generate many extra samples. The third is even worse because even more samples are computed. I don't know how to fix this. Perhaps if we use the slope and extrapolate a point and the computed point is reasonably close, we don't try extra samples. If it's very far off, we use more samples. However, I think we should just give up being smart. Let the user specify more grid points ore a smaller range.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694770&group_id=4933 
From: SourceForge.net <noreply@so...>  20030524 22:27:46

Bugs item #742909, was opened at 20030524 18:27 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=742909&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(x/2)) makes a mess Initial Comment: trigrat(sin(x/2)) => (%I*(SIN(x/2)*SIN(x)+COS(x/2)*COS(x)COS(x/2)) COS(x/2)*SIN(x)+SIN(x/2)*COS(x)SIN(x/2))/(2*SIN(x/2) ^2+2*COS(x/2)^2) Although this is correct, I doubt that this is what trigrat is supposed to do. After all, it has not eliminated sin (x/2); the result contains sin(x/2), but also contains sin^2+cos^2, so it doesn't seem "more linear" in any sense. Also, it is not a canonical form: trigrat(ev(sin (x/2),halfangles)) gives something else (even messier). Note also that sin(2*x) does not expand in trigrat.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&group_id=4933 
From: SourceForge.net <noreply@so...>  20030523 14:36:23

Bugs item #742362, was opened at 20030523 10:35 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742362&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat disappears after kill(all) Initial Comment: trigrat(1) => 1 (correct) kill(all) trigrat(1) => trigrat(1) !!!!!!!! kill(all) is removing trigrat, including apparently its autoload properties. There may be other functions like this, but I haven't looked.  >Comment By: Stavros Macrakis (macrakis) Date: 20030523 10:36 Message: Logged In: YES user_id=588346 Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742362&group_id=4933 
From: SourceForge.net <noreply@so...>  20030523 14:35:40

Bugs item #742362, was opened at 20030523 10:35 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=742362&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat disappears after kill(all) Initial Comment: trigrat(1) => 1 (correct) kill(all) trigrat(1) => trigrat(1) !!!!!!!! kill(all) is removing trigrat, including apparently its autoload properties. There may be other functions like this, but I haven't looked.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742362&group_id=4933 
From: SourceForge.net <noreply@so...>  20030520 17:19:07

Bugs item #739547, was opened at 20030518 20:18 Message generated for change (Comment added) made by vvzhy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739547&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: xmaxima oddity Initial Comment: The following commands cause the output not to return in Xmaxima running with clisp: (C1) to_lisp(); Type (run) to restart [1]> (macsymatoplevel) clisp 2.29 maxima 5.9.0.1cvs  >Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20030520 17:19 Message: Logged In: YES user_id=366498 It seems that xmaxima expect ; after every command no matter lisp or maxima. So after to_lisp(); you can work with lisp by typing t ; nil ; (print 111) ; etc. The real problem is that (run) under xmaxima relults in lisp error. In addition I discovered that to_lisp(); doesn't work GCL. Maxima just silently exit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739547&group_id=4933 
From: SourceForge.net <noreply@so...>  20030520 16:19:31

Bugs item #740567, was opened at 20030520 09:19 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=740567&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima 5.9.0 & GCL 2.5.2 Initial Comment: Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by CATCH. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Backtrace: SYSTEM:UNIVERSALERRORHANDLER Broken at MACSYMATOPLEVEL. MAXIMA>> Unrecoverable error: Segmentation violation.. /usr//libexec/maxima/5.9.0/maximarunlisp: line 391: 7330 Abortado (core dumped) "$1" $extra_args $load_arg eval '(run)' This error happens with Maxima compiled from maxima5.9.0.tar.gz, or installed from rpms: maxima5.9.01.i386.rpm and maximaexecgcl5.9.01.i386.rpm.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740567&group_id=4933 
From: SourceForge.net <noreply@so...>  20030519 22:13:42

Bugs item #740134, was opened at 20030519 18:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sum evals first argument inconsistently Initial Comment: Consider foo: i^2; sum('foo,i,0,2) => 3*foo (correct) sum(foo,i,0,2) => 3*i^2 WRONG sum(foo,i,0,n) => 'sum(i^2,i,0,n) (correct) In the case where upperlimitlowerlimit is a known integer, simpsum is checking whether foo is free of i *before* evaluating foo. I believe the correct way to handle this case is as follows: First evaluate foo with i bound to itself, and check if that result is free of i. If so, return the product. If not, *substitute* (don't evaluate) i=lowerlimit, i=lowerlimit+1, etc. This means that sum(print(i),i,1,2) would print "i", and not "1 2". That makes it consistent with Integrate: integrate('foo,i,0,2) => 2*foo (correct) integrate(foo,i,0,2) => 8/3 (correct) integrate(foo,i,0,n) => n^3/3 (correct) It also makes it consistent with Integrate in the presence of sideeffects: integrate(print(i),i,0,1) prints i sum(print(i),i,0,1) currently prints 0 1 but in this proposal would print i It is true that it would also create some funny situations. Currently, sum(integrate(x^i,x),i,0,2) evaluates correctly to x+x^2/2+x^3/3. Under this proposal, it would also evaluate *correctly*, but would first ask whether i+1 is zero or nonzero. Unless, that is, simpsum binds i to be an integer and to have a value >=lowerlimit and <=upperlimit (which is a sensible thing to do anyway). Now consider sum(integrate(1/(x^i+1),i),i,0,1) This currently correctly evaluates to x/2+log(x+1). Under the proposal, however, it would evaluate to a sum of noun forms, since the integral does not exist in closed form. I think we can live with that; an ev (...,integrate) takes care of it. But I still like the proposal. After all, if you set the result of the integration expression above to a temporary variable (which seems like a sensible thing to do), you will run into the original bad behavior.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 
From: SourceForge.net <noreply@so...>  20030519 08:32:06

Bugs item #738848, was opened at 20030516 16:15 Message generated for change (Comment added) made by kratt5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 Category: Share Libraries Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Poverseries error for 1/(1t)^2 Initial Comment: It seems powerseries(1(ab*t)^n, t, 0) produces an error for n=2, but is correct for n=1,3,4: (C1) POWERSERIES(1/(ab*t)^2, t, 0); INF ==== \ I1  I1  2 I1 (D1) > a b (I1 + 1) t / ==== I1 = 0 [I believe that powers of a and b above have opposite signs].  Comment By: Martin Rubey (kratt5) Date: 20030519 08:32 Message: Logged In: YES user_id=651552 This is fixed with the fix for [727542] powerseries wrong/fix Martin (please, somebody merge it into cvs, it is IMPORTANT!)  Comment By: Nobody/Anonymous (nobody) Date: 20030517 18:32 Message: Logged In: NO (C1) verbose:true; (D1) TRUE (C2) POWERSERIES(1/(ab*t)^2, t, 0); In the first simplification we have returned: 1  2 2 2 b t  2 a b t + a trying to do a rational function expansion of 1  2 2 2 b t  2 a b t + a Using a special rule for expressions of form M  N (A + C VAR ) Here we have [N = 2, A =  a, C = b, M = 1] INF ==== \ I1  I1  2 I1 (D2) > a b (I1 + 1) t / ==== I1 = 0 (C3)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 
From: SourceForge.net <noreply@so...>  20030518 20:22:37

Bugs item #739547, was opened at 20030518 15:18 Message generated for change (Settings changed) made by starseeker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739547&group_id=4933 >Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: xmaxima oddity Initial Comment: The following commands cause the output not to return in Xmaxima running with clisp: (C1) to_lisp(); Type (run) to restart [1]> (macsymatoplevel) clisp 2.29 maxima 5.9.0.1cvs  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739547&group_id=4933 
From: SourceForge.net <noreply@so...>  20030518 20:22:25

Bugs item #739552, was opened at 20030518 15:22 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=739552&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: Commercial Macsyma matrix entry Initial Comment: The commercial Macsyma apparently allows for the following matrix entry notation: > mat: [a, b, c; d, e, f]; > works in Macsyma and genrates this error: > > at: [a, b, c; > ^ > (C1) Incorrect syntax: Too many ]'s > d, e, f] > ^ > (C1) Incorrect syntax: Premature termination of input at ;. > ; > ^ Clearly this involves an update to the Maxima parser, and probably the Matrix code as well.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739552&group_id=4933 
From: SourceForge.net <noreply@so...>  20030518 20:18:02

Bugs item #739547, was opened at 20030518 15:18 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=739547&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: xmaxima oddity Initial Comment: The following commands cause the output not to return in Xmaxima running with clisp: (C1) to_lisp(); Type (run) to restart [1]> (macsymatoplevel) clisp 2.29 maxima 5.9.0.1cvs  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739547&group_id=4933 
From: SourceForge.net <noreply@so...>  20030518 05:37:19

Bugs item #739350, was opened at 20030518 00: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=739350&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 7 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: to_lisp behavior Initial Comment: all tests with : Maxima version: 5.9.0.1cvs Maxima build date: 12:38 4/27/2003 host type: i686pclinuxgnu In cmucl 18e to_lisp(); behaves perfectly, but in the other lisps there appear to be issues, ranging from minor to fatal: gcl 2.5.2  running to_lisp(); causes the system to exit. clisp 2.29  (run) works for return, but (macsymatoplevel) doesn't sbcl 0.7.14  both commands work, but to_lisp(); takes a very long time to return a command prompt. Thanks to Franz Kafka for point out this bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=739350&group_id=4933 
From: SourceForge.net <noreply@so...>  20030517 18:32:39

Bugs item #738848, was opened at 20030516 09:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 Category: Share Libraries Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Poverseries error for 1/(1t)^2 Initial Comment: It seems powerseries(1(ab*t)^n, t, 0) produces an error for n=2, but is correct for n=1,3,4: (C1) POWERSERIES(1/(ab*t)^2, t, 0); INF ==== \ I1  I1  2 I1 (D1) > a b (I1 + 1) t / ==== I1 = 0 [I believe that powers of a and b above have opposite signs].  Comment By: Nobody/Anonymous (nobody) Date: 20030517 11:32 Message: Logged In: NO (C1) verbose:true; (D1) TRUE (C2) POWERSERIES(1/(ab*t)^2, t, 0); In the first simplification we have returned: 1  2 2 2 b t  2 a b t + a trying to do a rational function expansion of 1  2 2 2 b t  2 a b t + a Using a special rule for expressions of form M  N (A + C VAR ) Here we have [N = 2, A =  a, C = b, M = 1] INF ==== \ I1  I1  2 I1 (D2) > a b (I1 + 1) t / ==== I1 = 0 (C3)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 
From: SourceForge.net <noreply@so...>  20030516 16:15:53

Bugs item #738848, was opened at 20030516 09:15 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=738848&group_id=4933 Category: Share Libraries Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Poverseries error for 1/(1t)^2 Initial Comment: It seems powerseries(1(ab*t)^n, t, 0) produces an error for n=2, but is correct for n=1,3,4: (C1) POWERSERIES(1/(ab*t)^2, t, 0); INF ==== \ I1  I1  2 I1 (D1) > a b (I1 + 1) t / ==== I1 = 0 [I believe that powers of a and b above have opposite signs].  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=738848&group_id=4933 