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}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(6) 
2

3
(2) 
4

5
(3) 
6

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

14
(3) 
15
(1) 
16
(4) 
17

18
(2) 
19

20
(1) 
21
(5) 
22
(3) 
23

24

25
(2) 
26
(4) 
27
(1) 
28
(3) 
29
(1) 
30
(1) 




From: SourceForge.net <noreply@so...>  20101101 20:51:28

Bugs item #3101075, was opened at 20101101 22:51 Message generated for change (Tracker Item Submitted) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3101075&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: Aleksas Domarkas (alex108) Assigned to: Nobody/Anonymous (nobody) Summary: limit bug Initial Comment: wrong: (%i1) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0); (%o1) und wrong: (%i2) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0,plus); (%o2) inf correct: (%i3) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0,minus); (%o3) 1/60 correct: (%i4) tlimit((2+cos(x))/(x^3*sin(x))3/x^4,x,0); (%o4) 1/60 (%i5) build_info()$ 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=3101075&group_id=4933 
From: SourceForge.net <noreply@so...>  20101101 20:00:26

Bugs item #3101043, was opened at 20101101 22:00 Message generated for change (Tracker Item Submitted) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3101043&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: Aleksas Domarkas (alex108) Assigned to: Nobody/Anonymous (nobody) Summary: limit bug Initial Comment: wrong: (%i1) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0); (%o1) und wrong: (%i2) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0,plus); (%o2) inf correct: (%i3) limit((2+cos(x))/(x^3*sin(x))3/x^4,x,0,minus); (%o3) 1/60 correct: (%i4) tlimit((2+cos(x))/(x^3*sin(x))3/x^4,x,0); (%o4) 1/60 (%i5) build_info()$ 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=3101043&group_id=4933 
From: SourceForge.net <noreply@so...>  20101101 19:39:31

Bugs item #3093408, was opened at 20101023 03:01 Message generated for change (Settings changed) 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: Closed >Resolution: Fixed 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: 20101101 20:39 Message: The documentation has been updated in solve_rec.texi revision 1.13. Closing this bug report as fixed. Dieter Kaiser  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...>  20101101 19:14:55

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: Closed >Resolution: Works For Me 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: 20101101 20:14 Message: As reported on this thread Maxima gets the correct limit. With tlimit or gruntz Maxima is fast too. Closing this bug report as "works for me". Dieter Kaiser  Comment By: Aleksas Domarkas (alex108) Date: 20101029 07: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 03: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 04: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 02: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 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...>  20101101 19:10:34

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: Closed 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: 20101101 20:10 Message: The documentation says in externalinterface.txt now says: *generaldisplayprefix* : string printed before each displayed output label Closing this bug report. Dieter Kaiser  Comment By: Volker (vfbraun) Date: 20101031 20: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 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...>  20101101 18:57:26

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: Closed >Resolution: Fixed 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: 20101101 19:57 Message: Fixed as suggest in mnewton.mac revision 1.15. The variable newtonepsilon is always initialized with the value 10^8. Closing this bug report as fixed. Dieter Kaiser  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 