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}
(28) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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 