You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(4) 
S  M  T  W  T  F  S 






1

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

15

16

17

18
(1) 
19
(7) 
20
(3) 
21
(1) 
22

23
(5) 
24
(3) 
25
(4) 
26
(2) 
27

28

29
(3) 
30

31
(9) 






From: SourceForge.net <noreply@so...>  20101031 20:30:24

Bugs item #3099527, was opened at 20101031 05:39 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&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: Works For Me Priority: 5 Private: No Submitted By: Ching Guan Chao (observerchao) Assigned to: Nobody/Anonymous (nobody) Summary: a integrate(sin(exp(x), x) is different to Mathematica Initial Comment: The results of integrate(sin(exp(x), x) is different from Mathematica 7  Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  maxima: b(t):= expand(float(subst(x=t, integrate(sin(exp(x)), x)))); makelist(b(t), t, 0, 3); [0.62471325642771,0.25024394235267,0.073778082688431,0.018588783055919] Mathematica 7: Table[SinIntegral[Exp[x]], {x, 0, 3}] // N {0.946083, 1.82104, 1.49702, 1.55221}  Comment By: Aleksas Domarkas (alex108) Date: 20101031 22:30 Message: Proposition. integrate(sin(exp(x)), x)+%pi/2 (Maxima) =Integrate[Sin[Exp[x]], x] (Mathematica) =integrate(sin(exp(x)), x) (Maple) Maxima: (%i1) integrate(sin(exp(x)), x)+%pi/2$ (%i2) makelist(subst(x=k,%),k,0,3)$ (%i3) float(%)$ (%i4) expand(%); (%o4) [0.94608307036718,1.821040269147567,1.497018244106465,1.552207543738978] Mathematica: In[1]:= Integrate[Sin[Exp[x]], x] Out[1]= SinIntegral[E^x] In[2]:= Table[%, {x, 0, 3}] Out[42]= {SinIntegral[1], SinIntegral[E], SinIntegral[E^2], SinIntegral[E^3]} In[3]:= N[%] Out[3]= {0.946083, 1.82104, 1.49702, 1.55221} Maple: > integrate(sin(exp(x)), x); Si(exp(x)) > seq(subs(x=k,%),k=0..3); Si(exp(0)), Si(exp(1)), Si(exp(2)), Si(exp(3)) > evalf(%); 0.9460830704, 1.821040269, 1.497018244, 1.552207544  Comment By: Dieter Kaiser (crategus) Date: 20101031 13:46 Message: The function SinIntegral in Mathematica corresponds in Maxima with expintegral_si. (%i1) b(x):=float(expintegral_si(exp(x))); (%o1) b(x) := float(expintegral_si(exp(x))) (%i2) makelist(b(t),t,0,3); (%o2) [0.946083070367183, 1.821040269147567, 1.497018244106465, 1.552207543269926] This is the result of Mathematica too. The definition of the Exponential Integral Si is integrate(sin(t)/t,t,0,x) Maxima can not solve this integral symbolically. Closing this bug report as "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 20:22:29

Bugs item #3100138, was opened at 20101031 18:52 Message generated for change (Comment added) made by msp1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&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: Works For Me Priority: 5 Private: No Submitted By: MSP1 (msp1) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent evaluation in plot2d Initial Comment: I was trying to produce "staircase" plots of computed and experimental data held in a list when I found the problem illustrated in simplified form by the following lines. (%i1) askinteger(round(x)); /* No problem here */ (%o1) yes (%i2) define_variable(data, [1.2, 4.6, 7.2, 5.6, 2.3], float); (%o2) [1.2, 4.6, 7.2, 5.6, 2.3] (%i3) data[round(2.6)]; /* Nor here */ (%o3) 7.2 (%i4) plot2d(data[round(i)], [i, 1, 5]); /* but oops! */ apply: subscript must be an integer; found: round(i)  Comment By: MSP1 (msp1) Date: 20101031 20:22 Message: Thanks for the work around. That works for me even if the straight forwards way of doing it didn't! For future reference, why is this "trick" necessary? Having now found the documentation you mentioned, it says that the single quote in the denition of the function is "to prevent plot3d from failing when it realizes that the matrix will require integer indices". However the documentation also says that round(x) is integer and it evaluates as such in other contexts. So I'm still rather puzzled by this.  Comment By: Dieter Kaiser (crategus) Date: 20101031 19:47 Message: The documentation of plot3d has an example which shows the way to get a plot for an integer function. The trick is to use the quote operator when passing the function as an argument to the plot command: plot2d('data[round(i)], [i, 1, 5]); Closing this bug report as "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 19:47:36

Bugs item #3100138, was opened at 20101031 19:52 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&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: Works For Me Priority: 5 Private: No Submitted By: MSP1 (msp1) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent evaluation in plot2d Initial Comment: I was trying to produce "staircase" plots of computed and experimental data held in a list when I found the problem illustrated in simplified form by the following lines. (%i1) askinteger(round(x)); /* No problem here */ (%o1) yes (%i2) define_variable(data, [1.2, 4.6, 7.2, 5.6, 2.3], float); (%o2) [1.2, 4.6, 7.2, 5.6, 2.3] (%i3) data[round(2.6)]; /* Nor here */ (%o3) 7.2 (%i4) plot2d(data[round(i)], [i, 1, 5]); /* but oops! */ apply: subscript must be an integer; found: round(i)  >Comment By: Dieter Kaiser (crategus) Date: 20101031 20:47 Message: The documentation of plot3d has an example which shows the way to get a plot for an integer function. The trick is to use the quote operator when passing the function as an argument to the plot command: plot2d('data[round(i)], [i, 1, 5]); Closing this bug report as "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 19:41:54

Bugs item #3098375, was opened at 20101029 13:56 Message generated for change (Comment added) made by vfbraun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Volker (vfbraun) Assigned to: Nobody/Anonymous (nobody) Summary: generaldisplayprefix missing in some circumstances Initial Comment: The generaldisplayprefix is not printed in front of "incorrect syntax:" errors with maxima 5.22.1: Maxima 5.22.1 http://maxima.sourceforge.net using Lisp ECL 10.4.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; incorrect syntax: = is not a prefix operator 1== ^ (%i2) 1=1; <generaldisplayprefix>(%o2) 1 = 1 Maxima 5.20.1 behaved differently: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 10.2.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; Incorrect syntax: = is not a prefix operator (%i2) <generaldisplayprefix>(%o2) 1 (%i3) 1=1; <generaldisplayprefix>(%o3) 1 = 1 This breaks programs that parse the maxima command line interaction, for example, Sage.  >Comment By: Volker (vfbraun) Date: 20101031 15:41 Message: Thank you for the clarification! I agree that the new behavior is more consistent. It might be useful to add a sentence to "doc/implementation/externalinterface.txt" to document it.  Comment By: Dieter Kaiser (crategus) Date: 20101031 09:20 Message: The behavior has changed because of revision 1.59 of nparse.lisp. The change was related to the bug report ID: 1046653  input prompt appearing when it should not. For several Lisp, but not all, we had one or more input prompts after an error message. The code to show the place of the error did not work. Old behavior (Maxima 5.21): Example 1: (%i1) integrate(x,x,); Incorrect syntax: Illegal use of delimiter ) (%i1) Incorrect syntax: Premature termination of input at ;. (%i1) Example 2: (%i1) 1==1; Incorrect syntax: = is not a prefix operator (%i1) (%o1) 1 New behavior (Maxima 5.22): Example 1: (%i1) integrate(x,x,); incorrect syntax: Illegal use of delimiter ) integrate(x,x,) ^ (%i1) Example 2: (%i1) 1==1; incorrect syntax: = is not a prefix operator 1== ^ (%i1) I think the last examples show the correct and expected behavior. The error is reported correctly and we have no more additional input and output labels. The prefix *generaldisplayprefix* is printed before the output label. But the correct behavior is not to print input or output labels, if the Maxima parser has detected an error. I think the behavior to display an error now is correct and consistent. Therefore, I do not see a problem in Maxima. The old behavior was wrong. Nevertheless, this change might have broken other code outside of Maxima which depends on the wrong behavior. At this point I tend to say that we might close this bug report as 'works for me'. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 18:52:33

Bugs item #3100138, was opened at 20101031 18:52 Message generated for change (Tracker Item Submitted) made by msp1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&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: 5 Private: No Submitted By: MSP1 (msp1) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent evaluation in plot2d Initial Comment: I was trying to produce "staircase" plots of computed and experimental data held in a list when I found the problem illustrated in simplified form by the following lines. (%i1) askinteger(round(x)); /* No problem here */ (%o1) yes (%i2) define_variable(data, [1.2, 4.6, 7.2, 5.6, 2.3], float); (%o2) [1.2, 4.6, 7.2, 5.6, 2.3] (%i3) data[round(2.6)]; /* Nor here */ (%o3) 7.2 (%i4) plot2d(data[round(i)], [i, 1, 5]); /* but oops! */ apply: subscript must be an integer; found: round(i)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3100138&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 14:51:28

Bugs item #3093422, was opened at 20101023 03:23 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in mnewton Initial Comment: If maximainit.mac has fpprec:32; or higher precision, then the below happens: (%i1) load(mnewton); (%o1) C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac (%i2) mnewton(cos(x)=1/2,x,0.99); mnewton: the process doesn't converge or it converges too slowly. (%o2) [] (%i3) If one then changes fpprec: in the interactive session, it has no effect: mnewton still won't work with cos(x). Yet in the interactive session, if maximainit.mac has fpprec:31; or lower precision, one can set fpprec: much higher and mnewton will work. This bug with mnewton does not occur with sin(x), tan(x) or atan(x), which are some examples I tried. Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20101031 15:51 Message: At first, the precision of mnewton is controlled by the option variable newtonepsilon. This is documented: 'The variable `newtonepsilon' controls the precision of the approximations. It also controls if computations are performed with floats or bigfloats.' A change of fpprec should have no effect as long as the computation is switched to bigfloat numbers using the option variable newtonepsilon. See the examples in the documentation. But nevertheless we have a bug. The option variable newtonepsilon is initialized with the value of 10.0^(fpprec/2). The default value of fpprec is 16 and therefore, the default value of newtonepsilon should be 10.0^8 as documented. If the user has changed the value of fpprec, the option variable newtonepsilon no longer is initialized with the default value. But with the new value of fpprec. This does not make sense, if fpprec is increased beyond a value which is appropriate for floating point evaluations. We get no result, because the algorithm no longer converges. I think the best is, to initialize newtonepsilon always with a value of 10⁻8 as documented. This guarantees a value suitable for floating point evaluations. Dieter Kaiser  Comment By: jrredford (jrredford) Date: 20101026 01:20 Message: This problem also occurs with mnewton and cot(x), except this time with fpprec:33; or higher. If I change the fpprec: in the interactive session then I can make it much higher without this problem ocurring. With no maximainit.mac file or an empty maximainit.mac file: (%i1) load(mnewton); (%o1) C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac (%i2) mnewton(cot(x)=1/2,x,0.99); (%o2) [[x = 1.107148717794091]] With fpprec:33; or higher in the maximainit.mac file: (%i1) load(mnewton); (%o1) "C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac" (%i2) mnewton(cot(x)=1/2,x,0.99); mnewton: the process doesn't converge or it converges too slowly. (%o2) [] Again, below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 13:20:28

Bugs item #3098375, was opened at 20101029 19:56 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Volker (vfbraun) Assigned to: Nobody/Anonymous (nobody) Summary: generaldisplayprefix missing in some circumstances Initial Comment: The generaldisplayprefix is not printed in front of "incorrect syntax:" errors with maxima 5.22.1: Maxima 5.22.1 http://maxima.sourceforge.net using Lisp ECL 10.4.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; incorrect syntax: = is not a prefix operator 1== ^ (%i2) 1=1; <generaldisplayprefix>(%o2) 1 = 1 Maxima 5.20.1 behaved differently: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 10.2.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; Incorrect syntax: = is not a prefix operator (%i2) <generaldisplayprefix>(%o2) 1 (%i3) 1=1; <generaldisplayprefix>(%o3) 1 = 1 This breaks programs that parse the maxima command line interaction, for example, Sage.  >Comment By: Dieter Kaiser (crategus) Date: 20101031 14:20 Message: The behavior has changed because of revision 1.59 of nparse.lisp. The change was related to the bug report ID: 1046653  input prompt appearing when it should not. For several Lisp, but not all, we had one or more input prompts after an error message. The code to show the place of the error did not work. Old behavior (Maxima 5.21): Example 1: (%i1) integrate(x,x,); Incorrect syntax: Illegal use of delimiter ) (%i1) Incorrect syntax: Premature termination of input at ;. (%i1) Example 2: (%i1) 1==1; Incorrect syntax: = is not a prefix operator (%i1) (%o1) 1 New behavior (Maxima 5.22): Example 1: (%i1) integrate(x,x,); incorrect syntax: Illegal use of delimiter ) integrate(x,x,) ^ (%i1) Example 2: (%i1) 1==1; incorrect syntax: = is not a prefix operator 1== ^ (%i1) I think the last examples show the correct and expected behavior. The error is reported correctly and we have no more additional input and output labels. The prefix *generaldisplayprefix* is printed before the output label. But the correct behavior is not to print input or output labels, if the Maxima parser has detected an error. I think the behavior to display an error now is correct and consistent. Therefore, I do not see a problem in Maxima. The old behavior was wrong. Nevertheless, this change might have broken other code outside of Maxima which depends on the wrong behavior. At this point I tend to say that we might close this bug report as 'works for me'. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 11:46:39

Bugs item #3099527, was opened at 20101031 04:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&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: Works For Me Priority: 5 Private: No Submitted By: Ching Guan Chao (observerchao) Assigned to: Nobody/Anonymous (nobody) Summary: a integrate(sin(exp(x), x) is different to Mathematica Initial Comment: The results of integrate(sin(exp(x), x) is different from Mathematica 7  Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  maxima: b(t):= expand(float(subst(x=t, integrate(sin(exp(x)), x)))); makelist(b(t), t, 0, 3); [0.62471325642771,0.25024394235267,0.073778082688431,0.018588783055919] Mathematica 7: Table[SinIntegral[Exp[x]], {x, 0, 3}] // N {0.946083, 1.82104, 1.49702, 1.55221}  >Comment By: Dieter Kaiser (crategus) Date: 20101031 12:46 Message: The function SinIntegral in Mathematica corresponds in Maxima with expintegral_si. (%i1) b(x):=float(expintegral_si(exp(x))); (%o1) b(x) := float(expintegral_si(exp(x))) (%i2) makelist(b(t),t,0,3); (%o2) [0.946083070367183, 1.821040269147567, 1.497018244106465, 1.552207543269926] This is the result of Mathematica too. The definition of the Exponential Integral Si is integrate(sin(t)/t,t,0,x) Maxima can not solve this integral symbolically. Closing this bug report as "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&group_id=4933 
From: SourceForge.net <noreply@so...>  20101031 03:39:45

Bugs item #3099527, was opened at 20101031 11:39 Message generated for change (Tracker Item Submitted) made by observerchao You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&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: Ching Guan Chao (observerchao) Assigned to: Nobody/Anonymous (nobody) Summary: a integrate(sin(exp(x), x) is different to Mathematica Initial Comment: The results of integrate(sin(exp(x), x) is different from Mathematica 7  Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  maxima: b(t):= expand(float(subst(x=t, integrate(sin(exp(x)), x)))); makelist(b(t), t, 0, 3); [0.62471325642771,0.25024394235267,0.073778082688431,0.018588783055919] Mathematica 7: Table[SinIntegral[Exp[x]], {x, 0, 3}] // N {0.946083, 1.82104, 1.49702, 1.55221}  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3099527&group_id=4933 
From: SourceForge.net <noreply@so...>  20101029 17:56:42

Bugs item #3098375, was opened at 20101029 13:56 Message generated for change (Tracker Item Submitted) made by vfbraun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Volker (vfbraun) Assigned to: Nobody/Anonymous (nobody) Summary: generaldisplayprefix missing in some circumstances Initial Comment: The generaldisplayprefix is not printed in front of "incorrect syntax:" errors with maxima 5.22.1: Maxima 5.22.1 http://maxima.sourceforge.net using Lisp ECL 10.4.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; incorrect syntax: = is not a prefix operator 1== ^ (%i2) 1=1; <generaldisplayprefix>(%o2) 1 = 1 Maxima 5.20.1 behaved differently: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 10.2.1 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) 1+1; <generaldisplayprefix>(%o1) 2 (%i2) 1==1; Incorrect syntax: = is not a prefix operator (%i2) <generaldisplayprefix>(%o2) 1 (%i3) 1=1; <generaldisplayprefix>(%o3) 1 = 1 This breaks programs that parse the maxima command line interaction, for example, Sage.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098375&group_id=4933 
From: SourceForge.net <noreply@so...>  20101029 11:13:37

Bugs item #3098123, was opened at 20101029 06:13 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098123&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: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: (complex float)^0 Initial Comment: OK: (%i6) (2.0)^0; (%o6) 1.0 Not consistent with (%o6): (%i7) (2.0 + %i)^0; (%o7) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3098123&group_id=4933 
From: SourceForge.net <noreply@so...>  20101029 05:17:57

Bugs item #3094299, was opened at 20101024 21:18 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  Comment By: Aleksas Domarkas (alex108) Date: 20101029 08:17 Message: To use tlimit (%i1) showtime:true$ Evaluation took 0.0000 seconds (0.0000 elapsed) (%i2) tlimit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x,0); Evaluation took 0.0000 seconds (0.0000 elapsed) (%o2) 8  Comment By: jrredford (jrredford) Date: 20101026 04:50 Message: Here's what I obtained: (%i1) showtime:true; Evaluation took 0.0000 seconds (0.0000 elapsed) (%o1) true (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 62.8400 seconds (62.8400 elapsed) (%o2) 8 Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20101025 05:02 Message: FWIW, tlimit finds the limit in a hundredth of a second or so on my computer. gruntz(<expr>, x, 0, 'plus) also takes a fraction of a second.  Comment By: Pevzi (pevzi) Date: 20101025 03:15 Message: Hm, yes, that's correct. So it seems that I didn't wait enough time while my Eee was performing calculations. But for me, one minute to find a limit is too long (for example, SymPy finds this in 45 seconds), so maybe it's a sort of bug anyway?  Comment By: Dieter Kaiser (crategus) Date: 20101024 22:27 Message: For the record: It take a long time (61 sec on my computer), but I get a result: Maxima version: 5.22post Maxima build date: 19:22 10/22/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.40 Evaluation took 0.0000 seconds (0.0020 elapsed) using 70.789 KB. (%o1) (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 61.4400 seconds (64.9250 elapsed) using 4959.743 MB. (%o2) 8 I think the result is correct. Dieter Kaiser  Comment By: Pevzi (pevzi) Date: 20101024 21:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101026 01:50:30

Bugs item #3094299, was opened at 20101024 18:18 Message generated for change (Comment added) made by jrredford You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  Comment By: jrredford (jrredford) Date: 20101026 01:50 Message: Here's what I obtained: (%i1) showtime:true; Evaluation took 0.0000 seconds (0.0000 elapsed) (%o1) true (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 62.8400 seconds (62.8400 elapsed) (%o2) 8 Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20101025 02:02 Message: FWIW, tlimit finds the limit in a hundredth of a second or so on my computer. gruntz(<expr>, x, 0, 'plus) also takes a fraction of a second.  Comment By: Pevzi (pevzi) Date: 20101025 00:15 Message: Hm, yes, that's correct. So it seems that I didn't wait enough time while my Eee was performing calculations. But for me, one minute to find a limit is too long (for example, SymPy finds this in 45 seconds), so maybe it's a sort of bug anyway?  Comment By: Dieter Kaiser (crategus) Date: 20101024 19:27 Message: For the record: It take a long time (61 sec on my computer), but I get a result: Maxima version: 5.22post Maxima build date: 19:22 10/22/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.40 Evaluation took 0.0000 seconds (0.0020 elapsed) using 70.789 KB. (%o1) (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 61.4400 seconds (64.9250 elapsed) using 4959.743 MB. (%o2) 8 I think the result is correct. Dieter Kaiser  Comment By: Pevzi (pevzi) Date: 20101024 18:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101026 00:22:38

Bugs item #3086681, was opened at 20101013 10:31 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3086681&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: alberto (albertoblah) Assigned to: Nobody/Anonymous (nobody) Summary: load(lapack) does not work Initial Comment: I have wxMaxima 0.8.6 with Maxima 5.22.1 installed on Windows 7. Everything works fine but when I attempt to load("lapack") the call seems having some problems because it produces no output (if I write load("vect") I see the path of the loaded mac file) and I can only write in the same cell where I have written load("lapack") but I can't do anything and I have to quit wxMaxima. I tried to download the latest lapack folder from the share libraries on CVS but nothing changed. I hope you can help me.  >Comment By: Raymond Toy (rtoy) Date: 20101025 20:22 Message: Since the command line version works as expected, I'm inclined to say that the issue is with wxMaxima and not maxima. Did you clear out everything before running in wxMaxima? If you didn't, it should work very quickly since everything is compiled already. If you do this from the commandline, it should also work very quickly. Can you try that?  Comment By: alberto (albertoblah) Date: 20101019 03:55 Message: I tried load(lapack) from command line maxima but nothing is printed, I just see the hard disk led keeps blinking for a few seconds and then nothing, no output, no prompt. So I uninstalled Maxima, deleted all the directory tree in ProgramFiles/Maxima, installed Maxima again, and tried load(lapack) from command line maxima, after a flooding of output about "Compiling dgesvd.lisp" and so on, an output line appeared with the path to the mac file, and then I got again the prompt. So I tried the same in wxMaxima but nothing. But it still works in the command line.  Comment By: Robert Dodier (robert_dodier) Date: 20101019 00:09 Message: Try load(lapack) using the command line user interface. load(lapack) compiles all the lapack files so it takes a long time the first time you load it. WxMaxima gathers all the output before displaying it, so you see nothing until the process is complete, but the command line user interface prints messages as they are generated. Please post another comment on this bug report to let us know how it turns out.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3086681&group_id=4933 
From: SourceForge.net <noreply@so...>  20101025 23:20:37

Bugs item #3093422, was opened at 20101023 01:23 Message generated for change (Comment added) made by jrredford You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in mnewton Initial Comment: If maximainit.mac has fpprec:32; or higher precision, then the below happens: (%i1) load(mnewton); (%o1) C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac (%i2) mnewton(cos(x)=1/2,x,0.99); mnewton: the process doesn't converge or it converges too slowly. (%o2) [] (%i3) If one then changes fpprec: in the interactive session, it has no effect: mnewton still won't work with cos(x). Yet in the interactive session, if maximainit.mac has fpprec:31; or lower precision, one can set fpprec: much higher and mnewton will work. This bug with mnewton does not occur with sin(x), tan(x) or atan(x), which are some examples I tried. Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: jrredford (jrredford) Date: 20101025 23:20 Message: This problem also occurs with mnewton and cot(x), except this time with fpprec:33; or higher. If I change the fpprec: in the interactive session then I can make it much higher without this problem ocurring. With no maximainit.mac file or an empty maximainit.mac file: (%i1) load(mnewton); (%o1) C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac (%i2) mnewton(cot(x)=1/2,x,0.99); (%o2) [[x = 1.107148717794091]] With fpprec:33; or higher in the maximainit.mac file: (%i1) load(mnewton); (%o1) "C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac" (%i2) mnewton(cot(x)=1/2,x,0.99); mnewton: the process doesn't converge or it converges too slowly. (%o2) [] Again, below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&group_id=4933 
From: SourceForge.net <noreply@so...>  20101025 05:18:25

Bugs item #3092375, was opened at 20101021 14:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3092375&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: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: display2d changes TeX output Initial Comment: In 5.22.1, I get different results from tex(expr,false) under display2d:true and display2d:false regardless of interface. For example, (%i1) display2d:false$tex(x^2,false); (%o2) "$$x^2$$\ " Robert Dodier was kind enough to suggest the following: The presence of the backslash is actually a minor bug; the string has an embedded newline (which is no problem) and the right way to display that is to just continue the string on the next line (sans backslash). With a backslash, it negates the newline and the next line is pasted onto the preceding one. If anybody wants to look at it, I think MSIZEATOM is the culprit.  >Comment By: Robert Dodier (robert_dodier) Date: 20101024 23:18 Message: I'm assuming the bug is that there is a spurious backslash in the output. So I've committed r1.39 src/grind.lisp which prevents the spurious backslash from being printed. Closing this report as fixed in that respect. If the intent in this report is that the bug is that a string is displayed differently when display2d=false versus display2d=true, well, that's how it is supposed to be.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3092375&group_id=4933 
From: SourceForge.net <noreply@so...>  20101025 02:02:57

Bugs item #3094299, was opened at 20101024 14:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  >Comment By: Raymond Toy (rtoy) Date: 20101024 22:02 Message: FWIW, tlimit finds the limit in a hundredth of a second or so on my computer. gruntz(<expr>, x, 0, 'plus) also takes a fraction of a second.  Comment By: Pevzi (pevzi) Date: 20101024 20:15 Message: Hm, yes, that's correct. So it seems that I didn't wait enough time while my Eee was performing calculations. But for me, one minute to find a limit is too long (for example, SymPy finds this in 45 seconds), so maybe it's a sort of bug anyway?  Comment By: Dieter Kaiser (crategus) Date: 20101024 15:27 Message: For the record: It take a long time (61 sec on my computer), but I get a result: Maxima version: 5.22post Maxima build date: 19:22 10/22/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.40 Evaluation took 0.0000 seconds (0.0020 elapsed) using 70.789 KB. (%o1) (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 61.4400 seconds (64.9250 elapsed) using 4959.743 MB. (%o2) 8 I think the result is correct. Dieter Kaiser  Comment By: Pevzi (pevzi) Date: 20101024 14:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101025 00:15:51

Bugs item #3094299, was opened at 20101025 02:18 Message generated for change (Comment added) made by pevzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  Comment By: Pevzi (pevzi) Date: 20101025 08:15 Message: Hm, yes, that's correct. So it seems that I didn't wait enough time while my Eee was performing calculations. But for me, one minute to find a limit is too long (for example, SymPy finds this in 45 seconds), so maybe it's a sort of bug anyway?  Comment By: Dieter Kaiser (crategus) Date: 20101025 03:27 Message: For the record: It take a long time (61 sec on my computer), but I get a result: Maxima version: 5.22post Maxima build date: 19:22 10/22/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.40 Evaluation took 0.0000 seconds (0.0020 elapsed) using 70.789 KB. (%o1) (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 61.4400 seconds (64.9250 elapsed) using 4959.743 MB. (%o2) 8 I think the result is correct. Dieter Kaiser  Comment By: Pevzi (pevzi) Date: 20101025 02:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101024 19:27:06

Bugs item #3094299, was opened at 20101024 20:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  >Comment By: Dieter Kaiser (crategus) Date: 20101024 21:27 Message: For the record: It take a long time (61 sec on my computer), but I get a result: Maxima version: 5.22post Maxima build date: 19:22 10/22/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.40 Evaluation took 0.0000 seconds (0.0020 elapsed) using 70.789 KB. (%o1) (%i2) limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0); Evaluation took 61.4400 seconds (64.9250 elapsed) using 4959.743 MB. (%o2) 8 I think the result is correct. Dieter Kaiser  Comment By: Pevzi (pevzi) Date: 20101024 20:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101024 18:22:23

Bugs item #3094299, was opened at 20101025 02:18 Message generated for change (Comment added) made by pevzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  Comment By: Pevzi (pevzi) Date: 20101025 02:22 Message: Oh, wait, of course that expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x, 0) I found that bug while using Sage and accidently copied it in Sage format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101024 18:18:58

Bugs item #3094299, was opened at 20101025 02:18 Message generated for change (Tracker Item Submitted) made by pevzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pevzi (pevzi) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima hangs when trying to find the limit Initial Comment: When I try this expression: limit(tan(sqrt(x))*log(1+8*sqrt(x))/sin(x), x=0) maxima hangs permanently.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3094299&group_id=4933 
From: SourceForge.net <noreply@so...>  20101023 22:17:17

Bugs item #3093408, was opened at 20101023 03:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in simplify_sum Initial Comment: On p. 876 of the PDF version of the Maxima Manual, Ver. 5.22 on the Maxima website, it gives an example of simplify_sum. But when I follow the example, the simplification doesn't work, contrary to what is shown in the manual. Below is the result I get: (%i1) display2d:false; (%o1) false (%i2) load("simplify_sum"); (%o2) "C:/program1/maxima/share/maxima/5.22.1/share/contrib/solve_rec/simplify_s um.mac" (%i3) sum(binom(n+k,k)/2^k, k, 0, n) + sum(binom(2*n, 2*k), k, 0, n); (%o3) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i4) simplify_sum(%); (%o4) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i5) Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20101024 00:17 Message: The reported problem is a documentation error. The function simplify_sum gives a different, but equivalent answer since Maxima 5.16. I think the initial revision of simply_sum is Maxima 5.13. I can reproduce the documented result for Maxima 5.13 until Maxima 5.15. The alias binom for the function binomial has been cut out with revision 1.86 of suprv.lisp and is not present since Maxima 5.20. Dieter Kaiser  Comment By: jrredford (jrredford) Date: 20101023 22:30 Message: Hi, Rtoy. That's the result I get when using binomial: (%i2) sum(binomial(n+k,k)/2^k, k, 0, n) + sum(binomial(2*n, 2*k), k, 0, n); (%o2) 'sum(binomial(n+k,k)/2^k,k,0,n)+'sum(binomial(2*n,2*k),k,0,n) (%i3) simplify_sum(%); Is n positive or zero? p; (%o3) 2^(2*n1)+2^n (%i4) simplify_sum(%o2); Is n positive or zero? z; (%o4) 2^(2*n1)+2^n (%i5) Page 878 of the aforecited Maxima Manual also uses "binom".  Comment By: Raymond Toy (rtoy) Date: 20101023 05:26 Message: Maybe binom should be binomial. When I do that, simplify_sum gives 2^(2n1)+2^n. So this is probably a documentation bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&group_id=4933 
From: SourceForge.net <noreply@so...>  20101023 20:30:25

Bugs item #3093408, was opened at 20101023 01:01 Message generated for change (Comment added) made by jrredford You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in simplify_sum Initial Comment: On p. 876 of the PDF version of the Maxima Manual, Ver. 5.22 on the Maxima website, it gives an example of simplify_sum. But when I follow the example, the simplification doesn't work, contrary to what is shown in the manual. Below is the result I get: (%i1) display2d:false; (%o1) false (%i2) load("simplify_sum"); (%o2) "C:/program1/maxima/share/maxima/5.22.1/share/contrib/solve_rec/simplify_s um.mac" (%i3) sum(binom(n+k,k)/2^k, k, 0, n) + sum(binom(2*n, 2*k), k, 0, n); (%o3) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i4) simplify_sum(%); (%o4) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i5) Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: jrredford (jrredford) Date: 20101023 20:30 Message: Hi, Rtoy. That's the result I get when using binomial: (%i2) sum(binomial(n+k,k)/2^k, k, 0, n) + sum(binomial(2*n, 2*k), k, 0, n); (%o2) 'sum(binomial(n+k,k)/2^k,k,0,n)+'sum(binomial(2*n,2*k),k,0,n) (%i3) simplify_sum(%); Is n positive or zero? p; (%o3) 2^(2*n1)+2^n (%i4) simplify_sum(%o2); Is n positive or zero? z; (%o4) 2^(2*n1)+2^n (%i5) Page 878 of the aforecited Maxima Manual also uses "binom".  Comment By: Raymond Toy (rtoy) Date: 20101023 03:26 Message: Maybe binom should be binomial. When I do that, simplify_sum gives 2^(2n1)+2^n. So this is probably a documentation bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&group_id=4933 
From: SourceForge.net <noreply@so...>  20101023 03:26:30

Bugs item #3093408, was opened at 20101022 21:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in simplify_sum Initial Comment: On p. 876 of the PDF version of the Maxima Manual, Ver. 5.22 on the Maxima website, it gives an example of simplify_sum. But when I follow the example, the simplification doesn't work, contrary to what is shown in the manual. Below is the result I get: (%i1) display2d:false; (%o1) false (%i2) load("simplify_sum"); (%o2) "C:/program1/maxima/share/maxima/5.22.1/share/contrib/solve_rec/simplify_s um.mac" (%i3) sum(binom(n+k,k)/2^k, k, 0, n) + sum(binom(2*n, 2*k), k, 0, n); (%o3) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i4) simplify_sum(%); (%o4) 'sum(binom(n+k,k)/2^k,k,0,n)+'sum(binom(2*n,2*k),k,0,n) (%i5) Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20101022 23:26 Message: Maybe binom should be binomial. When I do that, simplify_sum gives 2^(2n1)+2^n. So this is probably a documentation bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093408&group_id=4933 
From: SourceForge.net <noreply@so...>  20101023 01:23:27

Bugs item #3093422, was opened at 20101023 01:23 Message generated for change (Tracker Item Submitted) made by jrredford You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&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: jrredford (jrredford) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in mnewton Initial Comment: If maximainit.mac has fpprec:32; or higher precision, then the below happens: (%i1) load(mnewton); (%o1) C:/program1/maxima/share/maxima/5.22.1/share/contrib/mnewton.mac (%i2) mnewton(cos(x)=1/2,x,0.99); mnewton: the process doesn't converge or it converges too slowly. (%o2) [] (%i3) If one then changes fpprec: in the interactive session, it has no effect: mnewton still won't work with cos(x). Yet in the interactive session, if maximainit.mac has fpprec:31; or lower precision, one can set fpprec: much higher and mnewton will work. This bug with mnewton does not occur with sin(x), tan(x) or atan(x), which are some examples I tried. Below is the Maxima version I'm using: Maxima version: 5.22.1 Maxima build date: 11:48 8/13/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3093422&group_id=4933 