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

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091114 23:37:09

Bugs item #2787476, was opened at 20090505 21:41 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Žiga Lenarčič (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: 'diff() inconsistent Initial Comment: 'diff(x*y,x) gives the correct result (holds form), while 'diff(x,x) gives 1, calculates the differencial.  >Comment By: Dieter Kaiser (crategus) Date: 20091115 00:37 Message: 'diff(x,x) gives 1 because of simplification in the simplifying function simpderiv. We have a similar simplification for integrals: (%i9) 'integrate(1,x); (%o9) x Therefore, we can do something like (%i10) 'diff('integrate(1,x),x); (%o10) 1 Furthermore, the following simplification is build in: (%i15) 'diff(x,x,0); (%o15) x This works for an arbitrary expression too: (%i17) 'diff(sin(x),x,0); (%o17) sin(x) It might be arguable why Maxima does not do more simplifications of this type, but the implement simplifications are not wrong. I have no example, where these simplifications cause problems. So, I would suggest not to change the behavior of Maxima to simplify the examples in this bug report. Setting the status to pending and resolution "works for me". Dieter Kaiser  Comment By: Žiga Lenarčič (zigalenarcic) Date: 20090513 15:26 Message: Problem is in quoted diff, which should not evaluate, but it does in 'diff(x,x) case: (%i2) 'diff(x*y,x); d (%o2)  (x y) dx (%i3) 'diff(x,x); (%o3) 1 (%i4) 'diff(2*x,x); d (%o4)  (2 x) dx  Comment By: Nobody/Anonymous (nobody) Date: 20090513 13:27 Message: I may be stupid or blind, but I do not see the problem here. Would you like to see diff(x*x,x) resulting in x rather than 2x? May be your remark is more subtle than this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 22:11:24

Bugs item #2793888, was opened at 20090519 16:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793888&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  Differential eqns Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Renato AlvarezNodarse (raniuale) Assigned to: Nobody/Anonymous (nobody) Summary: additional package dynamics Initial Comment: The dynamic package does not work properly. The commands orbits, evolution, staircase and chaosgame etc do not accept any opctions including the ones used in the documentation. The problems is that the way os passing the options to plot2d fails. I include some examples: (%i12) evolution(cos(y), 2, 11, [yaxislabel, "y"], [xaxislabel,"n"]); Unknown plot option specified: yaxislabel #0: evolution(fun=cos(y),initial=2,n=11,options=[[yaxislabel,"y"],[xaxislabel,"n"]])(dynamics.mac line 54)  an error. To debug this try debugmode(true); Unknown plot option specified: real #0: staircase(fun=cos(y),initial=1,n=11,options=[[real,0,1.2]])(dynamics.mac line 96)  an error. To debug this try debugmode(true); (%i14) orbits(x+y^2, 0, 100, 400, [x,1,1.53,0.001], [pointsize,0.9],[ycenter,1.2], [yradius,0.4]); Graph passed to plot2d... Unknown plot option specified: pointsize #0: orbits(f=y^2+x,y0=0,n1=100,n2=400,domain=[x,1,1.53,0.001],options=[[pointsize,0.9],[ycenter,1.2],[yradius,0.4]])(dynamics.mac line 367)  an error. To debug this try debugmode(true); (%i15) chaosgame([[0, 0], [1, 0], [0.5, sqrt(3)/2]], [0.1, 0.1], 1/2, 30000, [pointsize,0.7]); Unknown plot option specified: pointsize #0: chaosgame(point=[[0,0],[1,0],[0.5,0.86602540378444]],p0=[0.1,0.1],b=0.5,n=30000,options=[[pointsize,0.7]])(dynamics.mac line 195)  an error. To debug this try debugmode(true); Cheers, Renato (ran@...) Renato  >Comment By: Dieter Kaiser (crategus) Date: 20091114 23:11 Message: The examples in the documentation works for me. The function plot2d is used for plotting. Therefore, only options which are known to plot2d can be passed. A look at the error messages shows that unknown options have been passed. E. g. the options xaxislabel and yaxislabel are not known to plot2d. the correct options are xlabel and ylabel. I have not looked at all examples in detail, but I think the error messages are verbose enough. Closing this bug report as invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2793888&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 21:45:10

Bugs item #2801819, was opened at 20090605 18:18 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2801819&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: spurious Principal Value message Initial Comment: (%i1) assume(p > 0); (%o1) [p>0] OK: (%i4) integrate(exp(p * t^2),t,minf,inf); (%o4) sqrt(%pi)/sqrt(p) OK, but not a principle value: (%i5) integrate(exp(pp * t^2),t,minf,inf); Is pp positive, negative, or zero?pos; Principal Value (%o5) sqrt(%pi)/sqrt(pp)  >Comment By: Dieter Kaiser (crategus) Date: 20091114 22:45 Message: This problem seems to be no longer present in Maxima 5.19post: (%i2) integrate(exp(pp * t^2),t,minf,inf); Is pp positive, negative, or zero? p; (%o2) sqrt(%pi)/sqrt(pp) Setting the status to pending and resolution to "works for me". Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20090605 20:18 Message: The difference between the two cases is in polesininterval. In the first case, there are no poles in the interval. In the second case, polesininterval thinks there are poles at minf and inf. Hence, maxima thinks we have a principal value integral.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2801819&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 21:22:57

Bugs item #2817882, was opened at 20090707 11:04 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2817882&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: Martin (mhs) Assigned to: Nobody/Anonymous (nobody) Summary: frame not documented Initial Comment: When defining a function of the name frame(), a warning is issued: Warning  you are redefining the Maxima function frame This function however does not seem to be documented: (%i16) ?? frame; 0: cframe_flag (Functions and Variables for ctensor) 1: frame_bracket (Functions and Variables for ctensor) 2: iframes (Functions and Variables for itensor) 3: iframe_bracket_form (Functions and Variables for itensor) Enter spaceseparated numbers, `all' or `none': none; (%o16) true  >Comment By: Dieter Kaiser (crategus) Date: 20091114 22:22 Message: I think the function $frame does not give any useful information, when called from the user. We should make the function invisibile and introduce a CL symbol. I would like to suggest to replace "$frame" with "breakframe". This name would match the existing naming scheme for the functions of the Maxima debugger. Remark: It is easy to replace $frame. We have only 4 calls in mdebug.lisp and one call in imaxima.lisp. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20090715 16:17 Message: Frame (aka $frame) is used by the maxima debugger to implement :frame command. It prints out information the current or selected stack frame. Not sure what to do about this. It's not clear whether the user is expected to be able to call this in any way other than via the :frame debugger command.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2817882&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 20:45:39

Bugs item #2897611, was opened at 20091114 10:46 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Erdmann Fricke (erdmannfricke) Assigned to: Nobody/Anonymous (nobody) Summary: wxmaxima 8.03 does not calculate a simple integral Initial Comment: wxmaxima 8.03 on my MacBook does not calculate the following integral: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4) (Mac OS 10.6; Maxima Version 5.19.2, Maxima build date: 17:49 9/1/2009; host type: i686appledarwin8.11.1; lispimplementationtype: SBCL; lispimplementationversion: 1.0.30) There were no problems with wxmaxima 8.02: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4)=891/50 (Ubuntu 9.10; Maxima Version 5.17.1, Maxima build date: 14:9 7/13/2009; host type: i686pclinuxgnu; lispimplementationtype: GNU Common Lisp (GCL); lispimplementationversion: GCL 2.6.7)  Comment By: Dieter Kaiser (crategus) Date: 20091114 13:18 Message: The integral works for me with wxMaxima 0.8.4, Maxima 5.19post and Ubuntu 9.10. The build info is: Maxima version: 5.19post Maxima build date: 23:36 11/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3467140630) This is the integral: (%i3) integrate(1/20*(x^4+16*x^391*x^2+216*x56),x,1,4); (%o3) 891/50 What is the error you get? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 20:44:13

Bugs item #2609426, was opened at 20090217 16:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2609426&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: Žiga Lenarčič (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( cos(a)/ sqrt((tan(a))^2 + 1), a, %pi/2, %pi/2 ); Initial Comment: Maxima can't caluculate definite integral integrate( cos(a)/ sqrt((tan(a))^2 + 1), a, %pi/2, %pi/2 ); It gives me The number 1 isn't in the domain of atanh  an error. To debug this try debugmode(true); If I calculate indefinite integral integrate( cos(a)/ sqrt((tan(a))^2 + 1), a); and manually put in integration limits, it gives the correct result %pi/2.  >Comment By: Dieter Kaiser (crategus) Date: 20091114 21:44 Message: Documentation for intanalysis has been added to Integration.texi revision 1.45. The integral of this bug report has been added as an example. Maxima does not give a wrong result and is able to solve the integral with the help of the option variable intanalysis. More might be possible, but this would be a feature request. Setting the status to pending and the resolution to "Works for me". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20090217 18:39 Message: FWIW, maxima is trying to find the roots of the denominator to see if there are any poles on the interval of integration. SOLVE is getting confused. A workaround would be to set intanalysis (undocumented) to false. Then integrate returns %pi/2.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2609426&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 20:43:45

Bugs item #2802006, was opened at 20090605 23:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2802006&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sqrt(x)+1), x, 0, 1); Initial Comment: Maxima can't solve this integral. I'm using maxima 5.17.1  >Comment By: Dieter Kaiser (crategus) Date: 20091114 21:43 Message: Documentation for intanalysis has been added to Integration.texi revision 1.45. The integral of this bug report has been added as an example. Maxima does not give a wrong result and is able to solve the integral with the help of the option variable intanalysis. More might be possible, but this would be a feature request. Setting the status to pending and the resolution to "Works for me". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20090707 20:36 Message: Maxima fails because polesininterval cannot determine if there are any poles in the integrand. This is basically a failure of solve (not $solve) to find any roots of sqrt(x)+1. If intanalysis is set to false, then maxima can evaluate this integral and the value is 22*log(2). (intanalysis should probably be documented.)  Comment By: Nobody/Anonymous (nobody) Date: 20090605 23:49 Message: bug persists in the 5.18.1 release  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2802006&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 20:33:09

Bugs item #2818144, was opened at 20090707 20:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2818144&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: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: intanalysis not documented Initial Comment: The variable intanalysis is not documented. It probably should be. When true, definite integration tries to find poles in the integrand in the interval of integration. If there are, then the integral is evaluated appropriately as a principal value integral. If intanalysis is false, this check is not performed and integration is done assuming there are no poles.  >Comment By: Dieter Kaiser (crategus) Date: 20091114 21:33 Message: The proposed documentation of intanalysis has been added in Integration.texi revision 1.45. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2818144&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 18:53:24

Bugs item #2716922, was opened at 20090327 14:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2716922&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: The execution hangs Initial Comment: Executing "run_testsuite (true, true)" in xmaxima takes 171 seconds. In wxMaxima after several hours it hangs. Maxima version: 5.17.1 Maxima build date: 19:10 12/18/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20091114 19:53 Message: First, the implementation of run_testsuite has changed. Now the command will be run_testsuite(display_all=true). Furthermore, I think this is a specific problem of wxMaxima on a Windows system. The result is displayed, when Maxima has finished its work. But with display_all = true the output is very large (several thousands of lines). It might be that wxMaxima hangs while trying to display the output of Maxima. On a Linux system I do not observe this problem with wxMaxima. The display of examples from the testsuite starts immediately. I think this is not a Maxima bug, but perhaps a wxMaxima problem on a Windows system. wxMaxima has a bug tracker too. Perhaps the bug should be added to the bug tracker of wxMaxima. 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=2716922&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 18:37:54

Bugs item #2184396, was opened at 20081021 15:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong factorization of sqrt() Initial Comment: Dear Developers of Maxima, I found a wrong behavihor of sqrt(). It is a principle that sqrt(X*Y) should not be factorized to sqrt(X)*sqrt(Y) unless X and Y can be judged to be nonnegative. I found a case in which this principle is broken. Here is a program for demonstration:  /* * wrong_factorization_of_sqrt.maxima: * * S.Adachi 2008/10/01 */ display2d:false; /* real for 1 <= x <= 2 */ correct:sqrt((11/x)*(2/x1)); /* real for 2sqrt(2) <= x <= 2+sqrt(2) */ INCORRECT:sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); INCORRECT_AT_2:at(INCORRECT,[x=2]); SHOULD_BE_POSITIVE:float(INCORRECT_AT_2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(wrong_factorization_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/307/wrong_factorization_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) correct:sqrt((11/x)*(2/x1)) (%o3) sqrt((11/x)*(2/x1)) (%i4) INCORRECT:sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) (%o4) sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) (%i5) INCORRECT_AT_2:at(INCORRECT,[x = 2]) (%o5) sqrt((2sqrt(2))/21)*sqrt(1(sqrt(2)+2)/2) (%i6) SHOULD_BE_POSITIVE:float(INCORRECT_AT_2) (%o6) 0.70710678118655 (%o7) "wrong_factorization_of_sqrt.maxima"  At first, as is seen from (%i2) and (%o2), sqrt(11/x)*(2/x1)) is not factorized to sqrt(...)*sqrt(...) in any automatic way. This is the correct behavihor. Next, as is seen from (%i3) and (%o3), sqrt(1(2sqrt(2))/x)*((2+sqrt(2))/x1)) is factorized to sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) in an automatic way. THIS IS AN INCORRECT BEHAVIOR. This expression is nonnegative for 2sqrt(2) <= x <= 2+sqrt(2). However, as is demonstrated by (%i4)(%o5), the calculated expression takes a negative value at x=2. Please stop the incorrect factorization of sqrt(X*Y) to sqrt(X)*sqrt(Y). Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20091114 19:37 Message: Fixed in compar.lisp revision 1.62. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091111 23:43 Message: I think I have found the bug in the routine compsplt. (defun compsplt (x) (cond ((atom x) (setq lhs x rhs 0)) ((atom (car x)) (setq lhs x rhs 0)) > ((not (null (cdr (symbols x)))) (compsplt2 x)) (t (compsplt1 x)))) At the marked line Maxima tests the CDR of the result of the function SYMBOLS. SYMBOLS returns a list of all variables of an expression. The list is of the form '($X $Y ...), where $X, $Y are the variables. Because COMPSPLT takes the CDR of SYMBOLS, one symbol in an expression is not recognized. Later in the algorithm the sign of this variable is not taken into account. For almost all expression this behavior seems to be no problem, but not for the examples of this bug report. When we change the test of the marked line: ((not (null (symbols x))) ... the sign of the given examples of this bug report are correct: (%i3) sign(1(2+sqrt(2))*x); (%o3) pnz (%i4) sign(1(2+sqrt(2))/x); (%o4) pnz and the reported expression does not longer factorize wrongly: (%i5) sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); (%o5) sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) One example of the testsuite no longer works. It is one of the new examples for the sign of the abs function. This is the example: (%i2) assume(abs(x)<%e/2+sin(1)); (%o2) [sin(1)+%e/2 > abs(x)] (%i3) is(x>2*%e); (%o3) true This will be the new result: (%i6) assume(abs(x)<%e/2+sin(1)); (%o6) [abs(x)+sin(1)+%e/2 > 0] (%i7) is(x>2*%e); (%o7) unknown This test no longer works, because the ordering of the terms will change. The reason is that COMPSPLT calls splitsum for one variable x in the expression too. So, with one exception the testsuite and the share_testsuite have no problems with the suggested change in COMPSPLT. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091111 01:27 Message: For the record. Again two example for a wrong sign: (%i3) sign(1(1+sqrt(2))/x); (%o3) neg (%i4) sign(1(1+sqrt(2))*x); (%o4) neg For these expressions the functions splitprod and splitsum are called. I have not figured out up to now the reason for the bug, but the variable x is lost somewhere and not taken into account to determine the sign. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091008 00:10 Message: Maxima can simplify the sqrt function correctly. No simplification, when the sign of a is not known: (%i1) sqrt(a*z); (%o1) sqrt(a*z) Simplification for a a positive or b a negative value: (%i2) assume(a>0)$ (%i3) sqrt(a*z); (%o3) sqrt(a)*sqrt(z) (%i4) assume(b<0)$ (%i5) sqrt(b*z); (%o5) sqrt(b)*sqrt(z) The problem of this bug report is one of the factors of the example. The sign is wrongly determined to be negative: (%i8) sign(1(2sqrt(2))/x); (%o8) neg Therefore Maxima does the above simplification, which is wrong. Dieter Kaiser  Comment By: boud (boud1) Date: 20090219 03:31 Message: There's another bug related to this one IMHO: [ 2202764 ] Taylor series of sqrt(1+xy) http://sourceforge.net/tracker/index.php?func=detail&aid=2202764&group_id=4933&atid=104933 [This is why i came here  i had a Taylor series bug that i think is equivalent.] HACK SOLUTION: The bug is solved for me (maxima 5.10.0, debianetch) by setting radexpand : false; ANALYSIS: However, i'm not convinced that this is a sufficient response to the bug. i don't really know maxima well enough to know what would be most reasonable. (1) Set radexpand to false by default? And add more warnings in the documentation (or do we expect users to learn mathematics elsewhere than in software documentation?) (2) Tell maxima not to rewrite sqrt(X) as %i sqrt(X) when domain:real ? (3) Extend the "is X positive, negative or zero?" question to the cases where it still needs to be asked but so far does not get asked, i.e. when deciding whether sqrt(X*Y) = sqrt(X)*sqrt(Y) or sqrt(X*Y) =  sqrt(X)*sqrt(Y) ? (4) Decide not to invert the order of an expression inside sqrt( ... ) if domain:real, except when it's sure that the expression is positive?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 16:59:17

Bugs item #2815422, was opened at 20090701 22:37 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815422&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: Xmaxima or other UI Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal point problem Initial Comment: Whenever I press the "." button on the number pad part of my keyboard wxMaxima version 0.8.2 inputs two "."s instead of just one as it should. If I press the button on the other part of the keyboard it works just fine. My keyboard is a Saitek Eclipse, my OS is Vista Ultimate x64. If you need any additional information let me know. Also, I often times am only after numerical computations so I use my number pad a lot when using wxMaxima and I would like the option to evaluate when enter is pressed to also include the enter key on the number pad.  >Comment By: Dieter Kaiser (crategus) Date: 20091114 17:59 Message: I think this is a very specific hardware problem which might be a problem of wxMaxima or even Vista. Furthermore, I think it is not a problem of Maxima and cannot solved within Maxima. Perhaps, this problem should be reported as a bug to the bug tracker of wxMaxima. Setting the status to pending and the resolution to "Wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815422&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 16:36:26

Bugs item #2895770, was opened at 20091111 08:51 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: apply(sum,...) behaves as if it is apply(sum,ev(...)) Initial Comment: Dear Developers of Maxima, This letter informs you that sum() and product() behave strangely when they are used as the first argument of apply(). The behavior actually observed for apply(sum, LIST_OF_ARGUMENTS) is not the expected one for it but coincides with the expected one for apply(sum, ev(LIST_OF_ARGUMENTS)). The same behavior is observed for apply(product, LIST_OF_ARGUMENTS). In my understanding, this is thought to be a bug for sum() and product(). Below, I will explain this behavior of sum() and product().  (1) Normal behavior of apply()  The following program demonstrates the normal behavior of apply(): ............................................................................... /* * behavior_of_apply.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[x]; OK1:apply(sin, arg_lst); x:%pi/2; OK2:apply(sin, arg_lst); OK3:apply(sin, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(behavior_of_apply.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/behavior_of_apply.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[x] (%o3) [x] (%i4) OK1:apply(sin,arg_lst) (%o4) sin(x) (%i5) x:%pi/2 (%o5) %pi/2 (%i6) OK2:apply(sin,arg_lst) (%o6) sin(x) (%i7) OK3:apply(sin,ev(arg_lst)) (%o7) 1 (%o8) "behavior_of_apply.maxima" ............................................................................... Please look at (%i6) and (%o6). At this point, arg_lst is equal to [x] and thereby the result of apply(sin, arg_lst) becomes sin(x). Even though the variable x is given the value %pi/2, this value is not used when apply() is called with the arguments sin and [x]. This is the normal expected behavior of apply(). If we want [x] to be evaluated in the current environment, we have to use ev(arg_lst) instead of arg_lst (see (%i7) and (%o7)).  (2) Strange behavior of sum() when it is used as 1st argument of apply()  The following program demonstrates the strange behavior of sum() when it is used as the first argument of apply(): ............................................................................... /* * strange_behavior_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[f(i), i, 1, n]; OK1:apply(sum, arg_lst); n:4; STRANGE:apply(sum, arg_lst); OK2:apply(sum, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(strange_behavior_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/strange_behavior_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[f(i),i,1,n] (%o3) [f(i),i,1,n] (%i4) OK1:apply(sum,arg_lst) (%o4) 'sum(f(i),i,1,n) (%i5) n:4 (%o5) 4 (%i6) STRANGE:apply(sum,arg_lst) (%o6) f(4)+f(3)+f(2)+f(1) (%i7) OK2:apply(sum,ev(arg_lst)) (%o7) f(4)+f(3)+f(2)+f(1) (%o8) "strange_behavior_of_sum.maxima" ............................................................................... In this example, arg_lst is set to [f(i),i,1,n] at (%i3). After arg_lst is prepared, n is set to 4 at (%i5). At (%i6), apply(sum,arg_lst) is calculated. At (%i7), apply(sum,ev(arg_lst)) is calculated. Both results become f(4)+f(3)+f(2)+f(1) as are seen at (%o6) and (%o7). This result is expected for apply(sum,ev(arg_lst)) but is never for apply(sum,arg_lst). The result expected for apply(sum,arg_lst) is 'sum(f(i),i,1,n). Namely, apply(sum,arg_lst) actually behaves as if it is apply(sum,ev(arg_lst)). I think that this is a bug.  (3) This bug of sum() is serious for programming.  This bug of sum() when it is supplied to the first argument of apply() is very serious one for writing programs. The bug causes a serious confusion of the object language and the observation language (programming language). To demonstrate how serious this bug is, I have prepared a toy program, which traces the process of calculation for a given expression. It is as follows: ............................................................................... /* * demonstration_of_strangeness_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; trace_calc(X) := trace_calc_sub(X, 0); trace_calc_sub(X, indent) := block([res], if (atom(X)) then ( print(smake(indent, " "),"[ATOM]:",X), res:X ) else ( block([n,i,arg_lst,a,b], print(smake(indent, " "),"[FUNC]: OP =",op(X)), arg_lst:[], n:length(X), for i:1 thru n do ( a:part(X,i), print(smake(indent, " "),"[FUNC]: ARG(",i,") = ",a," >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b]) ), res:apply(op(X),arg_lst), print(smake(indent, " "),"[FUNC]: RES = ",res) ) ), res); ex1_OK:a*b*F(n)+c*G(n); ex1_tr_OK:trace_calc(ex1_OK); ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n); ex2_tr_BAD:trace_calc(ex2_OK); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(demonstration_of_strangeness_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/demonstration_of_strangeness_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) trace_calc(X):=trace_calc_sub(X,0) (%o3) trace_calc(X):=trace_calc_sub(X,0) (%i4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%o4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%i5) ex1_OK:a*b*F(n)+c*G(n) (%o5) c*G(n)+a*b*F(n) (%i6) ex1_tr_OK:trace_calc(ex1_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*G(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = G(n) > [FUNC]: OP = G [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = G(n) [FUNC]: RES = c*G(n) [FUNC]: ARG( 2 ) = a*b*F(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = F(n) > [FUNC]: OP = F [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = F(n) [FUNC]: RES = a*b*F(n) [FUNC]: RES = c*G(n)+a*b*F(n) (%o6) c*G(n)+a*b*F(n) (%i7) ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n) (%o7) c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n) (%i8) ex2_tr_BAD:trace_calc(ex2_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*'product(g(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = 'product(g(i),i,1,n) > [FUNC]: OP = product [FUNC]: ARG( 1 ) = g(i) > [FUNC]: OP = g [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = g(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'product(g(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4) [FUNC]: ARG( 2 ) = a*b*'sum(f(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = 'sum(f(i),i,1,n) > [FUNC]: OP = sum [FUNC]: ARG( 1 ) = f(i) > [FUNC]: OP = f [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = f(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'sum(f(i),i,1,4) [FUNC]: RES = a*b*'sum(f(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o8) c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o9) "demonstration_of_strangeness_of_sum.maxima" ............................................................................... This expected result at (%o8) is c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n). But the calculated result is c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4). Namely, n is accidentally replaced by 4. This strange result is caused by the coincidence of the names of the variable n in the observation language (programming language) and the variable n in the object language (given expression). The value of the variable n used in the program is accidentally transferred to the variable n in the object expression.  (4) Strange behavior of product() when it is used as 1st argument of apply()  As is seen in the demonstration of (3), product() also has the same bug as sum() when it is supplied to the first argument of apply(). I do not know when this behavior of sum() and product() was brought into the code. It might be some relatively recent time. In this case, this behavior could be called a bug. Or, the behavior might originate at a long time ago in the code. In this case, you may say that this is not a bug but is a part of ''specification'' of Maxima. Even if you may, this is a serious inconsistency in Maxima and lets programming in Maxima be more difficult and be ugly since some workaround is necessary. I hope that this bug (in my understanding) will be fixed in future. Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20091114 17:36 Message: The function apply allows evaluates its arguments. This is the expected and the documented behaviour. (%i1) args:[f(i),i,0,n]; (%o1) [f(i),i,0,n] The variables of the list of arguments have not values: (%i2) apply('sum,args); (%o2) 'sum(f(i),i,0,n) Set the variable n: (%i3) n:4; (%o3) 4 The variable n now evaluates to the number 4: (%i4) [f(i),i,0,n]; (%o4) [f(i),i,0,4] apply evaluates its arguments too and the function sum evaluates the expression for an upper bound n:4: (%i6) apply('sum,args); (%o6) f(4)+f(3)+f(2)+f(1)+f(0) It is not possible to quote the argument: (%i8) apply('sum,[f(i),i,0,'n]); (%o8) f(4)+f(3)+f(2)+f(1)+f(0) Setting the status of this bug report to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 14:46:17

Bugs item #2838575, was opened at 20090816 18:29 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2838575&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: multiple evaluation & not Initial Comment: (%i1) a : not a$ (%i2) not a; Maxima encountered a Lisp error: Also (%i1) (a : b, b : c, c : d)$ OK: (%i4) not a; (%o4) not b I think %o5 should be not b. (%i5) apply("not", [a]); (%o5) not c Both of these (putative) bugs can be eliminated by deleting defmspec mnot function.  >Comment By: Dieter Kaiser (crategus) Date: 20091114 15:46 Message: I think we can not cut out the function MNOT. The current behaviour of the operator "not" is consistent with the other operators "and" and "or": (%i1) (a:b, b:c, c:d); (%o1) d (%i2) (x:y, y:z, z:w); (%o2) w The following expressions show one evaluation for every argument: (%i3) a and x; (%o3) b and y (%i4) a or x; (%o4) b or y (%i5) not a; (%o5) not b This is the putative wrong double evaluation for the logical operators: (%i6) apply("and", [a,x]); (%o6) c and z (%i7) apply("or", [a,x]); (%o7) c or z (%i8) apply("not", [a]); (%o8) not c This behaviour is due to the specific implementation of the evaluation scheme for the logical operators. This evaluation scheme takes care that predicates are evaluated with mevalp and not meval. But when we use the function apply, first the arguments are evaluated with meval due to a call to mevalargs, then the function MNOT is called which invoke a second evaluation via the function mevalp. Because mevalp is called in MNOT, we get the following results with the current implementation: (%i2) not (2>1); (%o2) false (%i3) not (1>2); (%o3) true When we cut out the function MNOT, we will get: (%i5) not (2>1); (%o5) 2 <= 1 (%i6) not (1>2); (%o6) 1 <= 2 and the predicates are no longer evaluated. At this point I have no idea what can be done to get both: 1. One evaluation when called with apply. 2. Evaluate predicates with mevalp. My conclusion is, that the current behaviour is by design. To change it, we have to reimplement the evaluation scheme of all logical operators. This might be a feature request. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2838575&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 12:47:52

Bugs item #2796194, was opened at 20090524 23:12 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&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: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: error doing a Fourier transform Initial Comment: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091114 13:47 Message: For the integral of the bug report I get the following with Maxima 5.19post: A not fully evaluated solution for x > 0: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Is x positive, negative, or zero? p; (%o1) %pi*(('limit(2*%pi*%e^(2*%pi*t)*x*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*cos(2*%pi*t*x),t,minf,plus)) /(4*%pi^2*x^2+4*%pi^2) +('limit(2*%pi*%e^(2*%pi*t)*x*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*cos(2*%pi*t*x),t,inf,minus)) /(4*%pi^2*x^2+4*%pi^2) +%i*(('limit(2*%pi*%e^(2*%pi*t)*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*x*cos(2*%pi*t*x),t,inf,minus)) /(4*%pi^2*x^2+4*%pi^2) ('limit(2*%pi*%e^(2*%pi*t)*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*x*cos(2*%pi*t*x),t,minf,plus)) /(4*%pi^2*x^2+4*%pi^2))) Again a solution for x < 0: (%i2) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Is x positive, negative, or zero? n; (%o2) %pi*(('limit(2*%pi*%e^(2*%pi*t)*x*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*cos(2*%pi*t*x),t,minf,plus)) /(4*%pi^2*x^2+4*%pi^2) +('limit(2*%pi*%e^(2*%pi*t)*x*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*cos(2*%pi*t*x),t,inf,minus)) /(4*%pi^2*x^2+4*%pi^2) +%i*(('limit(2*%pi*%e^(2*%pi*t)*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*x*cos(2*%pi*t*x),t,inf,minus)) /(4*%pi^2*x^2+4*%pi^2) ('limit(2*%pi*%e^(2*%pi*t)*sin(2*%pi*t*x) 2*%pi*%e^(2*%pi*t)*x*cos(2*%pi*t*x),t,minf,plus)) /(4*%pi^2*x^2+4*%pi^2))) But a Lisp error for x = 0: (%i3) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Is x positive, negative, or zero? z; **  Continuable Error Invalid trig kernel in tvarlim If you continue (by typing 'continue'): Return from COMMONLISP:BREAK loop The following restarts are also available: MACSYMAQUIT :R1 Maxima toplevel Break 1 [2]> :r1 Maxima restarted. This could be the correct solution for x=0. For this case one factor of the integrand vanishs and the integral is divergent: (%i4) integrate(%pi*exp(2*%pi*t),t,minf,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); Setting the resolution to "none". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20090723 07:37 Message: Reopening this item. I still see it. Appears to be triggered because TVARLIM does not have a case for MPLUS expressions.  Comment By: SourceForge Robot (sfrobot) Date: 20090722 04: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: Raymond Toy (rtoy) Date: 20090707 20:46 Message: This no longer appears to happen in the CVS version. (The result isn't great since it contains a lot of limit expressions, but the Lisp error is gone. I did not check to see if the answer makes sense or not.) Marking as pending/worksforme  Comment By: Rich Hennessy (rvh2007) Date: 20090524 23:18 Message: I get this same error in my pwdefint() function in pw.mac. I don't think it is a problem with pwdefint(). See the second case. (%i1) pwdefint(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. case 2: (%i1) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) load(abs_integrate); (%o2) C:/Maxima5.18.1/share/maxima/5.18.1/share/contrib/integration/abs_integrate.mac (%i3) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 12:32:22

Bugs item #2069818, was opened at 20080823 17:25 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2069818&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: Xmaxima or other UI Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Henry Peters (henry09) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima v.5.13 crashes when changing preferences. Initial Comment: In Ubuntu 8.04.1, Maxima version 5.13.0 crashes when I try to make any change in the preference window. I downloaded & installed via the 'Add/Remove' package manager. Also, the program opens as not a full screen (perhaps there is some bug associated with (saving of preferences?)). Thanks, Henry  >Comment By: Dieter Kaiser (crategus) Date: 20091114 13:32 Message: I have tried xmaxima with Maxima 5.19post on Ubuntu 9.10. I do not have the observed problem. But I do not install the packages from Debian, but install from cvs. There are some known problems with the Debian packages. Perhaps this problem is related to such a problem too. Setting the status to pending and the resolution to works for me. Dieter Kaiser  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080825 22:32 Message: Logged In: YES user_id=1270759 Originator: NO Hello, As mentioned in a previous post, I installed maxima, xmaxima and wxmaxima from the ubuntu (hardy) repository and all three work as expected. I suggest you post a message to the main maxima list describing your problem in some more detail. If others have had the same problem, perhaps you can get better answers. Mario  Comment By: Henry Peters (henry09) Date: 20080825 05:04 Message: Logged In: YES user_id=2191245 Originator: YES Hi Mario, Good to speak with an actual person with a name here! Yes, I downloaded wxmaxima & it works fine (with limited use). I am, however, trying to point my nose toward a Linux direction, & would like to stay there as much as possible, so hoping to resolve this little problem somehow. I am also wondering if there are something the equivalent in Linux to a preferences file that may have been or become corrupted (this did happen both in Windows & Macintosh)? Also, speaking of wxmaxima, I was exploring it this afternoon, & also checked my email (in Windows) & across the Maxima discussion list came an email regarding an upgrade... wondering if you know if it was for Wxmaxima or the Linux version (I believe they did not mention which). If it is Linux, perhaps the upgrade might fix my problem... of course, since I am on dialup here (*very* slow dialup!) that means a multihour down load. Oh well, I suppose I should check the downloads section. Any further suggestions would be welcome (from any perusing this bug chase). Henry  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080824 12:08 Message: Logged In: YES user_id=1270759 Originator: NO Henry, I uninstalled Maxima from synaptic and installed it again via de Add/Remove tool. After that I made some changes in Options/Preferences (font types and sizes) and Maxima didn't crash. On the other hand, xmaxima window doesn't fill the screen when you open it, but as far as I can say, it has been always so; I think this fact is not related to your problem. Probably, you already know that you can install the wxmaxima gui too; you can give it a try. Sorry, if this answer is not of much help and for my previous anonymous post. Mario Rodriguez  Comment By: Henry Peters (henry09) Date: 20080824 01:42 Message: Logged In: YES user_id=2191245 Originator: YES To reply to the sender of the comment below (Nobody), I am working in the xmaxima mode (just got the program, so "working" is not really an apt description). & hope it is good news that someone has somehow resolved this problem... (or rather, that it doesn't appear in the first place). The program, generally, seems to work ok (like I said, very limited use so far). I do dual boot with Windows XP which Maxima version I also downloaded last evening. That version looks great (!), as well as seems to function. Henry  Comment By: Nobody/Anonymous (nobody) Date: 20080823 23:53 Message: Logged In: NO I have just installed Maxima 5.13 in Ubuntu 8.04 via synaptic and everything seems to work fine, included xmaxima and wxmaxima. Maybe the original poster could give some more details. Are you working in text mode or through graphical interfaces (xmaxima, wxmaxima)?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2069818&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 12:18:11

Bugs item #2897611, was opened at 20091114 10:46 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&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: Erdmann Fricke (erdmannfricke) Assigned to: Nobody/Anonymous (nobody) Summary: wxmaxima 8.03 does not calculate a simple integral Initial Comment: wxmaxima 8.03 on my MacBook does not calculate the following integral: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4) (Mac OS 10.6; Maxima Version 5.19.2, Maxima build date: 17:49 9/1/2009; host type: i686appledarwin8.11.1; lispimplementationtype: SBCL; lispimplementationversion: 1.0.30) There were no problems with wxmaxima 8.02: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4)=891/50 (Ubuntu 9.10; Maxima Version 5.17.1, Maxima build date: 14:9 7/13/2009; host type: i686pclinuxgnu; lispimplementationtype: GNU Common Lisp (GCL); lispimplementationversion: GCL 2.6.7)  >Comment By: Dieter Kaiser (crategus) Date: 20091114 13:18 Message: The integral works for me with wxMaxima 0.8.4, Maxima 5.19post and Ubuntu 9.10. The build info is: Maxima version: 5.19post Maxima build date: 23:36 11/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3467140630) This is the integral: (%i3) integrate(1/20*(x^4+16*x^391*x^2+216*x56),x,1,4); (%o3) 891/50 What is the error you get? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 09:46:01

Bugs item #2897611, was opened at 20091114 10:46 Message generated for change (Tracker Item Submitted) made by erdmannfricke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&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: Erdmann Fricke (erdmannfricke) Assigned to: Nobody/Anonymous (nobody) Summary: wxmaxima 8.03 does not calculate a simple integral Initial Comment: wxmaxima 8.03 on my MacBook does not calculate the following integral: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4) (Mac OS 10.6; Maxima Version 5.19.2, Maxima build date: 17:49 9/1/2009; host type: i686appledarwin8.11.1; lispimplementationtype: SBCL; lispimplementationversion: 1.0.30) There were no problems with wxmaxima 8.02: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4)=891/50 (Ubuntu 9.10; Maxima Version 5.17.1, Maxima build date: 14:9 7/13/2009; host type: i686pclinuxgnu; lispimplementationtype: GNU Common Lisp (GCL); lispimplementationversion: GCL 2.6.7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&group_id=4933 
From: SourceForge.net <noreply@so...>  20091114 02:20:22

Bugs item #2887798, was opened at 20091028 09:31 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2887798&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: Xmaxima or other UI Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Windows process does not end Initial Comment: When is exit wxMaxima the window disappears but in the taskmanager the process is still active and usere 100%CPU, also turning my laptop in a heating device. OS: WinXP  >Comment By: SourceForge Robot (sfrobot) Date: 20091114 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: 20091030 22:03 Message: I can not observe this behavior when closing wxMaxima. The process maxima.exe is always stopped too. I have found one way to get the observed behavior: When I kill wxMaxima in the task manager, the process maxima.exe is still alive and uses 99% of the CPU time. But this is not the usual way to finish a program. Perhaps the process wxMaxima had to be killed because it hangs. More information is needed to confirm this report as a bug, e.g. the version of Maxima and wxMaxima. Perhaps we can get more information. Setting the status of this bug report on "pending". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2887798&group_id=4933 