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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


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

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100330 21:15:17

Bugs item #2607007, was opened at 20090216 21:41 Message generated for change (Comment added) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2607007&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  Plotting Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Lester Ingber (ingber) Assigned to: Jaime E. Villate (villate) Summary: legend does not work Initial Comment: Here's a simple example: plot3d(x+y,[x,3,3],[y,4,4],[legend,"Line"]); I get "y+x ___________" instead of "Line" for a title/legend? I cannot get the title to use legend? If I have an expression name instead of a function, I get the generic title of "Function _________". At least [legend, false] works, but I'd like to put titles in my graphs. Thanks. Lester  >Comment By: Jaime E. Villate (villate) Date: 20100330 21:15 Message: option "legend" now works in plot3d.  Comment By: Jaime E. Villate (villate) Date: 20100330 21:15 Message: The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: Jaime E. Villate (villate) Date: 20090226 08:55 Message: The problem is that legend was implemented only for plot2d and not for plot3d. I'll try to make it work in plot3d before the next release or if I can't I will then make a note in the documentation to alert to that fact. Thank you for your report.  Comment By: Robert Dodier (robert_dodier) Date: 20090225 18:09 Message: Appears that legend works OK for plot2d but not for plot3d. I'm assigning this report to the person who was last working on the plot options.  Comment By: Lester Ingber (ingber) Date: 20090216 21:45 Message: P.S. I'm using Maxima under Cygwin on a Thinkpad with XP Pro. This seems to be a gnuplot option. I could not get legend to work with other gnuplot options which do work fine. E.g.: plot__smni_Lag:if abs(smni_Lag) > 1.0 then 0 else smni_Lag$ plot3d(plot__smni_Lag,[ze,80,80],[zi,30,30],[gnuplot_term, ps],[gnuplot_out_file,"c:/cygwin/home/ingber/smni_Lag.ps"],[xlabel, "M_E"],[ylabel,"M_I"],[zlabel,"L"],[legend,"smni_Lag"],['grid,40,15])$ Lester  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2607007&group_id=4933 
From: SourceForge.net <noreply@so...>  20100330 19:25:20

Bugs item #2979579, was opened at 20100330 19:20 Message generated for change (Comment added) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979579&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  Plotting Group: None >Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: plot3d with format xmaxima does not work in Xmaxima Initial Comment: A 3d plot using the plot_format xmaxima, for instance: plot3d(x^2y^2,[x,2,2],[y,2,2],[grid,12,12],[plot_format,xmaxima]) works fine when maxima is run in a terminal, but it fails when maxima is run from xmaxima.  >Comment By: Jaime E. Villate (villate) Date: 20100330 19:25 Message: This bug has been fixed. There was a typo in xmaxima_def.lisp and a missing right brace in plot.lisp.  Comment By: Jaime E. Villate (villate) Date: 20100330 19:25 Message: The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979579&group_id=4933 
From: SourceForge.net <noreply@so...>  20100330 19:20:28

Bugs item #2979579, was opened at 20100330 19:20 Message generated for change (Tracker Item Submitted) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979579&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  Plotting Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: plot3d with format xmaxima does not work in Xmaxima Initial Comment: A 3d plot using the plot_format xmaxima, for instance: plot3d(x^2y^2,[x,2,2],[y,2,2],[grid,12,12],[plot_format,xmaxima]) works fine when maxima is run in a terminal, but it fails when maxima is run from xmaxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979579&group_id=4933 
From: SourceForge.net <noreply@so...>  20100330 11:49:58

Bugs item #2979140, was opened at 20100330 09:58 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979140&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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: error in help of gamma_incomplete() Initial Comment: help for gamma_incomplete(): "The incomplete upper gamma function A&S 6.5.2: gamma_incomplete(a, x) = integrate(exp(t)*t^(a1), t, 0, x)" should be: "The incomplete upper gamma function A&S 6.5.2: gamma_incomplete(a, x) = integrate(exp(t)*t^(a1), t, x, inf)" (wrong limits of the integral)  Maxima version: 5.19.2 Maxima build date: 17:49 9/1/2009 host type: i686appledarwin8.11.1 lispimplementationtype: SBCL lispimplementationversion: 1.0.30  >Comment By: Dieter Kaiser (crategus) Date: 20100330 13:49 Message: Thank you for the report. This documentation error has been fixed already and is not present in the current CVS version of Maxima. Closing this bug report as works for me. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979140&group_id=4933 
From: SourceForge.net <noreply@so...>  20100330 07:58:13

Bugs item #2979140, was opened at 20100330 07:58 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979140&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: error in help of gamma_incomplete() Initial Comment: help for gamma_incomplete(): "The incomplete upper gamma function A&S 6.5.2: gamma_incomplete(a, x) = integrate(exp(t)*t^(a1), t, 0, x)" should be: "The incomplete upper gamma function A&S 6.5.2: gamma_incomplete(a, x) = integrate(exp(t)*t^(a1), t, x, inf)" (wrong limits of the integral)  Maxima version: 5.19.2 Maxima build date: 17:49 9/1/2009 host type: i686appledarwin8.11.1 lispimplementationtype: SBCL lispimplementationversion: 1.0.30  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2979140&group_id=4933 
From: SourceForge.net <noreply@so...>  20100329 13:48:14

Bugs item #2781127, was opened at 20090425 08:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2781127&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: bfpsi0 of complex Initial Comment: bfpsi(complex) doesn't return a number in rectangular form. Maybe the value is correct, but it doesn't inspire much confidence: (%i3) bfpsi0(4.5 + %i,15); (%o3)  (1.0b0 ((1.0b0 ((1.0b0 ((1.0b0 ((1.0b0 8.33333333333333b2 1.0b0 (  2.10927960927961b2) .... 2  >Comment By: Raymond Toy (rtoy) Date: 20100329 09:48 Message: Some well placed calls to rectform in bfpsi0 fixes this. And the result appears to be correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2781127&group_id=4933 
From: SourceForge.net <noreply@so...>  20100329 13:00:48

Bugs item #2697197, was opened at 20090320 07:31 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2697197&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: jacobi_p & float overflow Initial Comment: Using SBCL: (%i1) jacobi_p(300,42, 12,10.1); Maxima encountered a Lisp error: arithmetic error FLOATINGPOINTOVERFLOW signalled  >Comment By: Raymond Toy (rtoy) Date: 20100329 09:00 Message: I don't think Maxima should do anything about this. There's some expectation that floatingpoint arithmetic should be fast and we're willing to trade that for things like overflow and underflow. Automatically changing to bigfloats could cause a huge slowdown.  Comment By: Barton Willis (willisbl) Date: 20090413 07:21 Message: We have jacobi_p(300,42, 12,10.1) = 4.85995022683574b405. I suppose Maxima could automatically switch to big floats when floating point overflow happens, but I don't know how that would work.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2697197&group_id=4933 
From: SourceForge.net <noreply@so...>  20100329 02:39:08

Bugs item #2880797, was opened at 20091016 18:27 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880797&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: bad answer in integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) Initial Comment: integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) returns %pi but the result is 2*%pi The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Add new artifact' link on that page. Please include the following build information with your bug report:  Maxima version: 5.19.1 Maxima build date: 1:42 10/16/2009 host type: i686pclinuxgnu lispimplementationtype: ECL lispimplementationversion: 9.8.4  The above information is also available from the Maxima function build_info(). this bug is not in 5.13 reported at http://groups.google.cz/group/sagedevel/t/f82e24efdfe23b07 Robert Marik  >Comment By: Raymond Toy (rtoy) Date: 20100328 22:39 Message: Fixed as suggested in sin.lisp, rev 1.60.  Comment By: Raymond Toy (rtoy) Date: 20091105 12:55 Message: This looks like a good solution. But is it too broad? Are there cases in trigint where triginverses set to $all would be wrong? Maybe a more careful solution that only sets it when we use the tan(x/2) substitution would be better? I couldn't see any cases where it would produce incorrect results.  Comment By: Andrej Vodopivec (andrejv) Date: 20091017 17:45 Message: The problem comes from (%i1) integrate(sqrt(sin(x)^2+cos(x)^2), x); (%o1) atan(tan(x)) This integral is done with substitution (tan(x/2)) and we need to make sure that atan(tan(x))=x when we backsubstitute. Here is a simple patch which fixes the problem: Index: sin.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/sin.lisp,v retrieving revision 1.51 diff u r1.51 sin.lisp  sin.lisp 18 Aug 2009 16:59:37 0000 1.51 +++ sin.lisp 17 Oct 2009 21:33:54 0000 @@ 1503,7 +1503,7 @@ getout (setq y (list '(mtimes) *yy* *yz*)) get2 (setq y (simplify y))  (return (substint repl 'x (integrator y 'x))))) + (return (let (($triginverses '$all)) (substint repl 'x (integrator y 'x)))))) (defmvar $integration_constant_counter 0) (defmvar $integration_constant '$%c)  Comment By: Dieter Kaiser (crategus) Date: 20091016 18:57 Message: Perhaps this bug is not a new problem. The answer of Maxima depends on the flag triginversers. (%i36) integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi),triginverses:true; (%o36) %pi (%i37) integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi),triginverses:all; (%o37) 2 %pi The default value of triginverses has changed with revision 1.33 of trigi.lisp from 'all to 'true. The bug was not visible in the past with the standard value 'all of triginverses. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880797&group_id=4933 
From: SourceForge.net <noreply@so...>  20100329 02:20:48

Bugs item #712468, was opened at 20030331 04:44 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712468&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: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Values list (etc.) modified destructively Initial Comment: Many of the infolists, including Values, are modified destructively. This leads to confusing behavior like the following: (c1) values; (d1) [a,b,c] (c2) kill(values)$ (c3) d1; (d3) [] or (c4) values; (d4) [a,b,c] (c5) newval: 23$ (c6) d4; (d6) [a,b,c,newval] The Values list is modified destructively both for additions (new variable defined) and for deletions (kill). In both cases, it is strictly for effiency. In the addition case, it is to add new variables to the end (rather than the beginning) of the list efficiently. Even if we want to keep the value list in order of addition (rather than reverse order of addition), the efficiency price of using nondestructive operations is trivial. After all, how many variables (or functions or rules or whatever) are you going to add? Uservisible objects should NOT be modified destructively! It makes for far too confusing semantics! Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: SourceForge Robot (sfrobot) Date: 20100329 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100314 21:35 Message: I think as long as we do not pass a copy of the lists to the user, but a reference to the global internal variable, the user observes the described effect of destructively modifications of a infolist. Instead of passing a reference we might support for all infolists a function which passes a copy of the list, e.g. (%i1) :lisp (defun $values () (copylist $values)) STYLEWARNING: redefining $VALUES in DEFUN $VALUES (%i1) a:10$ b:20$ c:30$ Both the global variable values and the function values() show three variable: (%i4) values; (%o4) [a, b, c] (%i5) values(); (%o5) [a, b, c] We kill two variable: (%i6) kill(a,c); (%o6) done The output %o4 has been modified destructively, because it is a reference to the global variable $values. The output %o5 is not modified. We have passed a copy of the list. (%i7) %o4; (%o7) [b] (%i8) %o5; (%o8) [a, b, c] I would like to suggest to close this bug report as "Won't fix". If we support in addition a function, we double functionality which might confuse the user and if we change the implementation, a lot of code might be broken. A user who needs an infolist not to be modified can do a copy, e.g. with the command copy(values). Setting the status to pending and the resolution to "Won't fix". Perhaps, I see something completely wrong. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712468&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 17:55:57

Bugs item #2944431, was opened at 20100202 09:26 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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  Solving equations Group: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  Comment By: Aleksas Domarkas (alex108) Date: 20100328 20:55 Message: 1. (%i1) solve(7/10000*x^(1+874/1000)=500,x),simp=false; (%o1) [x=(5000000/7)^(937/500)^(1)] (%i2) ratsimp(%); (%o2) [x=5000000^(500/937)/7^(500/937)] (%i3) float(%), numer; (%o3) [x=1329.63071069307] 2. (%i4) f(x):=7/10000*x^(1+874/1000); (%o4) f(x):=7/10000*x^(1+874/1000) (%i5) t(x):=(f(x)f(500))/(x500); (%o5) t(x):=(f(x)f(500))/(x500) (%i6) limit(t(x),x,500); (%o6) 6559/(5*2^(1063/250)*125^(563/500)) (%i7) float(%), numer; (%o7) 0.29975567251994 3. (%i8) eq:1.5^x=34; (%o8) 1.5^x=34 (%i9) ratsimp(%); rat: replaced 1.5 by 3/2 = 1.5 (%o9) 3^x/2^x=34 (%i10) solve(eq,x),simp=false; rat: replaced 1.5 by 3/2 = 1.5 (%o10) [x=log(34)/log(3/2)] (%i11) float(%),numer; (%o11) [x=8.697075171448409]  Comment By: Raymond Toy (rtoy) Date: 20100315 15:44 Message: Oops. Maxima should be able to solve 1.5^x=34 (or equivalently (3/2)^x=34).  Comment By: Raymond Toy (rtoy) Date: 20100315 15:41 Message: 1. find_root(f(x)=500,x,0,10000) > 1329.63 2. limit(t(x),x,500) > infinity. This is a bug. But t(499.99999999999999) is not a bug. 499.999999999999999 rounds to 500.0 so we get a division by zero error. 3. find_root(1.5^x=34,x,1,10) > 8.697... You wanted numerical results, so solve is not really what you want to use. find_root is better suited. The limit is problem. But note that if you replace the floating point numbers with rationals, maxima can evaluate the limit: f1(x) := 7*10^(4)*x^(1874/1000)$ t1(x):=(f1(x)f1(500))/(x500)$ limit(t1(x),x,500) > 6559/(5*2^(1063/250)*125^(563/500)) I don't think there's anything wrong with maxima in any of these items.  Comment By: Nobody/Anonymous (nobody) Date: 20100202 23:37 Message: Thanks rtoy, but the bugs are causing problems. I, as a teacher, started to replace the TI Voyage 200, by maxima. The TI Voyage is very simply. You type solve and (almost) every equation will be solve. So maxima is one step back for my students. Ok, they are forced to think before they decide to solve an equation because they have to choose a function which is able to solve the equation, but, in my opinion, K12stuff should be solved in a very simply way. Maybe this post helps to fix the bugs. To the programmers: Thanks for maxima  Comment By: Raymond Toy (rtoy) Date: 20100202 16:27 Message: 1. Maxima converts the float number to rationals and is trying to solve 7/10000*s^(937/500). It seems that maxima did find the roots, but is taking a very long time to sort all 937 roots. This is a bug. If you want numerical results, then perhaps find_root is what you're looking for. 2. That is due to the finite precision available with floating point. If you want to be able to do this with arbitrary precision use bfloats with enough digits. This is not a bug. 3. Yes, maxima cannot solve this equation. That is a bug. But for numerical answers, maybe find_root is what you're looking for.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 15:03:22

Bugs item #2907727, was opened at 20091202 15:19 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Integral with option integrate_use_rootsof :true Initial Comment: This integral previously crashed maxima, see bug 2906049. Now it gives the wrong answer. integrate_use_rootsof : true; integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); yields: lsum(((%r1^2*d+2*%r1*c+3*b)*g*log(QA%r1)*R)/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) but the correct answer is lsum(((%r1^2*d+2*%r1*c+3*b)*log(QA%r1))/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) I'm using Maxima version: 5.20post Maxima build date: 9:7 12/2/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3427367244) (memory 3468751644)  >Comment By: Raymond Toy (rtoy) Date: 20100328 11:03 Message: Fixed in sinint.lisp, rev 1.10  Comment By: Raymond Toy (rtoy) Date: 20100326 09:04 Message: I think multiplying by the leading factor is wrong. I think the algorithm is basically a partial fraction expansion of N(x)/D(x) = sum(A(n)/(xr(n)), n=1,N) where r(n) is a root of D(x). The constant A(n) can be determined by computing limit(N(x)*D(x)/(xr), x, r), but that's basically N(r)*at(diff(D(x),x), [x=r]). The code basically does this, but multiplies by the leading factor.  Comment By: Dieter Kaiser (crategus) Date: 20091202 17:52 Message: I had a look at wolfram alpha and I have got as a reference the following result: integral (d x^2+2 c x+3 b)/(g r x^3+d x^2+c x+b) dx = RootSum[#1^3 g r+#1^2 d+#1 c+b&, (#1^2 d log(x#1)+3 b log(x#1)+2 #1 c log(x#1))/(3 #1^2 g r+2 #1 d+c)&]+constant This corresponds to your solution. Maxima has an extra factor g*r. So, the algorithm now is working, but it seems to be wrong. The extra factor is the leading coefficient of the denominator. This factor is extracted and multiplied into the result by the algorithm. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 14:23:22

Bugs item #2924831, was opened at 20100102 03:56 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: file_type is wrong for ccl on mac os x Initial Comment: clozure cl compiled files have the extension .dx64fls on mac os x. file_type thinks this are demo files since it only checks the first character of the extension. load therefore fails to load compiled files.  Comment By: Raymond Toy (rtoy) Date: 20100325 15:07 Message: This is fine with me. I'll check it in shortly.  Comment By: Andrej Vodopivec (andrejv) Date: 20100311 03:48 Message: I think we can replace file_type in mload.lisp with (defun $file_type (fil &aux typ) (setq typ ($pathname_type fil)) (cond ((member typ (list "l" "lsp" "lisp") :test #'string=) '$lisp) ((member typ (list "mac" "mc" "demo" "dem" "dm1" "dm2" "dm3" "dmt") :test #'string=) '$maxima) (t '$object)))  Comment By: Raymond Toy (rtoy) Date: 20100204 08:05 Message: Perhaps file_type should be more explicit. So "max", "mac", "dem", and "demo" are maxima files; "l", "lsp", and "lisp" are lisp files, and everything else are object files. Maybe we can also let the user specify the association between the file extension and the file type?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&group_id=4933 
From: SourceForge.net <noreply@so...>  20100328 01:06:11

Bugs item #2977830, was opened at 20100328 01:06 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977830&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Implement a feature that shows work (=feature request) Initial Comment: It would be nice to have a feature that shows work like Wolfram Alpha does for students.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977830&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 16:16:49

Bugs item #2976744, was opened at 20100325 23:44 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&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  Plotting Group: None >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: postscript terminal requires manual reset of default termina Initial Comment: Bug reported by Leo Butler in the Users list: When using the gnuplot_pipes plot format, the use of [gnuplot_preamble,"set terminal postscript ...] appears to require that subsequent calls manually reset the terminal to the default.  >Comment By: Dieter Kaiser (crategus) Date: 20100327 17:16 Message: Setting the status to closed. The bug has been fixed already. Dieter Kaiser  Comment By: Jaime E. Villate (villate) Date: 20100326 14:40 Message: This bug has been fixed, but its solution has not been committed to the repository yet because the CVS sever is currently down. It will be committed when the server goes up again. The problem was introduced when the default gnuplot terminal command for Unix systems was changed from "x11" to empty. That was done to allow different installations to use their default terminal, which in most cases is better than "x11" (wxt is much nicer than x11). The change worked fine when the gnuplot format was used, because in that case a new gnuplot session is started for each plot command. However, when the gnuplot_pipes format is used, a plot command does not start a new gnuplot session but instead the plot is sent to an open gnuplot session. When the terminal was changed into postscript and then back to the default terminal, this last step did not change the terminal, leaving it as postscript. To avoid that problem while letting each site use its own default terminal, the default gnuplot terminal command will now be defined as "set term pop", which restores the initial terminal used when gnuplot was started; in fact, it is a good idea to use the same command at Windows sites, anticipating that different Windows versions of gnuplot might have a default terminal different from the "windows" terminal currently used.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 16:12:01

Bugs item #2976657, was opened at 20100325 20:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Usage of gammagreek and %gammagreek Initial Comment: Maxima uses the different symbols %gammagreek and gammagreek for the same function. In hyp.lisp the symbol %gammagreek is used: (%i1) z^a/a*hgfred([a],[a+1],z); (%o1) %gammagreek(a,z) But in hypgeo.lisp the symbol gammagreek is used: (%i2) assume(s>0,a>0)$ The integrand with %gammagreek does not work: (%i3) specint(%gammagreek(a,t)*exp(s*t),t); (%o3) 'specint(%gammagreek(a,t)*%e^(s*t),t) Now we use the symbol gammagreek: (%i4) specint(gammagreek(a,t)*exp(s*t),t); (%o4) gamma(a+1)*s^(a1)/(a*(1/s+1)^a) I think we should use only the symbol gammagreek. It might be even better to introduce the symbol gamma_greek to be more consistent with the names of other functions related to the gamma function. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100327 17:12 Message: The symbols %gammagreek and gammagreek have been replaced with gamma_greek in hyp.lisp revision 1.117 and hypgeo.lisp revision 1.75. gamma_greek is the lower incomplete gamma function. Closing this bug report as fixed. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100327 04:00 Message: I agree. It seems that gammagreek is the incomplete gamma function, the integral for 0 to x. Renaming it something besides gamma_greek would be good.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 14:45:06

Bugs item #2977217, was opened at 20100326 19:58 Message generated for change (Comment added) made by uhlst You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima can not integrate x*exp(1/2*(xm)^2) Initial Comment: Maxima can not integrate the function x*exp(1/2*(xm)^2) Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(x*exp(1/2*(xm)^2),x); 2 (x  m) /   [ 2 (%o1) I x %e dx ] / The correct solution would be (%i2) diff(exp(1/2*x^2+m*x1/2*m^2)+1/2*m*sqrt(%pi)*sqrt(2)*erf(1/2*sqrt(2)*x1/2*m*sqrt(2)),x); 2 2 x m 2 x m  (  )   + m x   sqrt(2) sqrt(2) 2 2 (%o2) m %e  (m  x) %e  Comment By: uhlst (uhlst) Date: 20100327 15:45 Message: Thank you for showing this "trick" with changevar. Is there a way that Maxima automatically does the correct substitution without giving it a hint with changevar? If e.g. the "1/2" in the exponent is removed, then Maxima has no problem to do the integration. Does Maxima not try itself some substitutions if integrate is called?  Comment By: Aleksas Domarkas (alex108) Date: 20100326 21:40 Message: (%i1) S:'integrate(x*exp(1/2*(xm)^2),x); (%o1) integrate(x*%e^((xm)^2/2),x) (%i2) changevar(S, y=xm, y, x); (%o2) integrate((y+m)*%e^(y^2/2),y) (%i3) ev(%, nouns); (%o3) (sqrt(%pi)*m*erf(y/sqrt(2)))/sqrt(2)%e^(y^2/2) Solution: (%i4) sol:subst(y=xm,%),rootscontract; (%o4) sqrt(%pi/2)*m*erf((xm)/sqrt(2))%e^((xm)^2/2) Test: (%i5) diff(sol,x)first(S)$ (%i6) expand(%); (%o6) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 12:58:57

Bugs item #2977398, was opened at 20100326 22:54 Message generated for change (Settings changed) made by umeboshi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: peach (umeboshi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x*(cos(x/2)),x) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  Comment By: peach (umeboshi) Date: 20100327 05:58 Message: Yes, I checked using newest version. Ｔｈｉｓ bug has been fixed in version Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. ＊＊＊＊＊＊＊＊＊＊＊ first version is Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100327 05:41 Message: What version are you using? Current CVS gives f(n) gives 2*x*sin(x/2)+4*cos(x/2). Marking as pending/worksforme  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 12:58:03

Bugs item #2977398, was opened at 20100326 22:54 Message generated for change (Comment added) made by umeboshi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&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  Integration Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: peach (umeboshi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x*(cos(x/2)),x) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  >Comment By: peach (umeboshi) Date: 20100327 05:58 Message: Yes, I checked using newest version. Ｔｈｉｓ bug has been fixed in version Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. ＊＊＊＊＊＊＊＊＊＊＊ first version is Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100327 05:41 Message: What version are you using? Current CVS gives f(n) gives 2*x*sin(x/2)+4*cos(x/2). Marking as pending/worksforme  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 12:41:43

Bugs item #2977398, was opened at 20100327 01:54 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&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  Integration Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: peach (umeboshi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x*(cos(x/2)),x) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  >Comment By: Raymond Toy (rtoy) Date: 20100327 08:41 Message: What version are you using? Current CVS gives f(n) gives 2*x*sin(x/2)+4*cos(x/2). Marking as pending/worksforme  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 12:11:59

Bugs item #2786017, was opened at 20090503 12:25 Message generated for change (Comment added) made by van_nek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: realonly in algsys.lisp Initial Comment: The option variable realonly is quite confusing since it does not find real solutions, but only solutions which are free of %i (purely using freeof). For example, when realonly is false, algsys ([x^4 + 1], [x]); returns [[x = (1)^(1/4)], [x = (1)^(1/4)*%i], [x = (1)^(1/4)], [x = (1)^(1/4)*%i]] But when realonly is true, it returns [[x = (1)^(1/4)], [x = (1)^(1/4)]] while it is natural to expect []. Maybe it is better to modify the behavior and filter roots by checking something like is_real(x) := is(trigsimp(imagpart(x)) = 0); and not just freeof(%i, x) With the freeof approach we may also omit real roots of irreducible polynomials: sol : map ('rhs, solve (3*x^3  3*x + 1)); [(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)) +(3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2), (3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2) +(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)), (3^(3/2)*%i/21/6)^(1/3)+1/(3*(3^(3/2)*%i/21/6)^(1/3))] map (lambda([x], freeof(%i, x)), sol); [false,false,false] map ('is_real, sol); [true,true,true] So when realonly and algexact are set to true, algsys ([3*x^3  3*x + 1], [x]) just returns [].  >Comment By: Volker van Nek (van_nek) Date: 20100327 13:11 Message: my recent cvs commit closes this report Volker van Nek  Comment By: Volker van Nek (van_nek) Date: 20100123 10:58 Message: Hi Alexey, yesterday I noticed this problem too and found your bug report. I think you are right, freeof(%i, x) is not a sufficient test to recognize nonzero imaginary parts. E.g. (1)^(1/4) passes. So I wonder why you did not fix that problem. You suggested the right thing. It is one line in src/algsys.lisp to change: 348352: (defun realonly (rootsl) (cond ((null rootsl) nil) ;; ((freeof '$%i (car rootsl)) ;; problem ((equal 0 (sratsimp ($imagpart (car rootsl)))) ;; fix ? (nconc (list (car rootsl)) (realonly (cdr rootsl)))) (t (realonly (cdr rootsl))))) This change passes the test suite. So I would commit this new line. Or do I overlook something? Why did you hesitate to commit? Volker van Nek  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 05:54:13

Bugs item #2977398, was opened at 20100326 22:54 Message generated for change (Tracker Item Submitted) made by umeboshi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: peach (umeboshi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x*(cos(x/2)),x) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977398&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 03:00:23

Bugs item #2976657, was opened at 20100325 15:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Usage of gammagreek and %gammagreek Initial Comment: Maxima uses the different symbols %gammagreek and gammagreek for the same function. In hyp.lisp the symbol %gammagreek is used: (%i1) z^a/a*hgfred([a],[a+1],z); (%o1) %gammagreek(a,z) But in hypgeo.lisp the symbol gammagreek is used: (%i2) assume(s>0,a>0)$ The integrand with %gammagreek does not work: (%i3) specint(%gammagreek(a,t)*exp(s*t),t); (%o3) 'specint(%gammagreek(a,t)*%e^(s*t),t) Now we use the symbol gammagreek: (%i4) specint(gammagreek(a,t)*exp(s*t),t); (%o4) gamma(a+1)*s^(a1)/(a*(1/s+1)^a) I think we should use only the symbol gammagreek. It might be even better to introduce the symbol gamma_greek to be more consistent with the names of other functions related to the gamma function. Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20100326 23:00 Message: I agree. It seems that gammagreek is the incomplete gamma function, the integral for 0 to x. Renaming it something besides gamma_greek would be good.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&group_id=4933 
From: SourceForge.net <noreply@so...>  20100327 02:21:49

Bugs item #2969482, was opened at 20100312 15:55 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: algsys: tried and failed to reduce system to a polynomial in Initial Comment: Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: SourceForge Robot (sfrobot) Date: 20100327 02:21 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100312 18:50 Message: Please, we need an example to see what might be wrong. Without an example this bug report is invalid. Setting the status to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 23:40:25

Bugs item #2977307, was opened at 20100326 22:35 Message generated for change (Settings changed) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977307&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  Integration Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/eusus3Ud () Assigned to: Nobody/Anonymous (nobody) Summary: x*cos(x/2) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977307&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 23:35:51

Bugs item #2977332, was opened at 20100326 23:34 Message generated for change (Settings changed) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977332&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  Integration Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/eusus3Ud () Assigned to: Nobody/Anonymous (nobody) Summary: x*cos(x/2) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977332&group_id=4933 