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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(2) 
2
(3) 
3
(12) 
4
(12) 
5
(6) 
6
(1) 
7
(2) 
8

9
(3) 
10
(4) 
11
(4) 
12
(6) 
13
(3) 
14
(1) 
15
(4) 
16

17

18

19
(6) 
20
(5) 
21

22
(2) 
23
(1) 
24
(4) 
25

26

27
(1) 
28

29
(2) 
30
(1) 



From: SourceForge.net <noreply@so...>  20100605 21:50:52

Bugs item #1959214, was opened at 20080507 06:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate() and array having lisp style name Initial Comment: Dear Developer of Maxima, I found that integrate() returns a wrong result if an array that has a lisp name ``?...'' is used in the argument of integrate(). Here is a demonstration program:  /* * integrate_and_array_of_lisp_name.maxima: * * S.Adachi 2008/05/06 */ display2d:false; integrate(1,?a[1],0,?a[2]); /* Maxima result ?a[1][2] should be ?a[2]. */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(integrate_and_array_of_lisp_name.maxima) batching #p/Volumes/HFS+2/home/adachi/work/294/integrate_and_array_of_lisp_name.maxima (%i2) display2d : false (%o2) false (%i3) integrate(1,?a[1],0,?a[2]) (%o3) ?a[1][2] (%o4) "integrate_and_array_of_lisp_name.maxima"  The correct value of this integration is ?a[2]. But Maxima returns ?a[1][2], which is wrong. I think that this is a bug of Maxima. In the following, I want to explain the situation in which I met the above bug of Maxima in order to motivate the kind Maxima developers to take the action to actually fix this bug. When I am writing a program in Maxima, I sometimes need an array that has some name which is unique and is dynamically determined in execution. In such a situation, I write a code like A:?gensym(), apply('array, [A,n]), ... < Work with dynamical array A > .. apply('remarray, [A]) The variable A stores a name ``?g....'' of the dynamical array that is generated. This name ``?g....'' is a lisp style name. In the present case, the work is to prepare a function of elements of the dynamical array and integrate the function. Then, when the written program is executed, it tells me that Maxima has the bug that I am now reporting. I hope that any variable in Maxima should not be discreminated by the reason that the variable simply has a lisp name. If it is so, what I am now reporting is truely a bug of Maxima, which is serious for people who write Maxima programs. Please fix this bug of Maxima. Sincerely yours, Satoshi Adachi P.S. (i) As a temporal workaround to write Maxima programs, I replace the line "A:?gensym()," in the above example by a line "A:eval_string(substring(string(?gensym()),2))," to use a Maxima style name "g...." instead of a lisp style name "?g...." (and keep being carefull not to use any name "g...." for other Maxima variables). This is an ugry workaround. (ii) If there is a better or standard way in Maxima to prepare some dynamical array that has a unique name on fly, please let me know. If someone tells me it, I will be happy.  >Comment By: Dieter Kaiser (crategus) Date: 20100605 23:50 Message: A Maxima user function gensym has been implemented in mutils.lisp revision 1.10. The documentation is in Miscellaneous.texi revision 1.27. This function can be used for the example of this bug report. I would like to suggest to close this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080623 00:13 Message: Logged In: YES user_id=501686 Originator: NO Here is a slightly different workaround. :lisp (defun $gensym () (cadr (dollarify (list (gensym))))) Then you can write A:gensym() instead of A:?gensym() and the generated symbols are Maxima identifiers (because they have the leading $ in the name).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 20:20:11

Bugs item #1969790, was opened at 20080522 20:31 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1969790&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: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: limits and subscripts Initial Comment: Maybe not wrong, but it's weird: (%i24) limit(mu[inf],x,inf); (%o24) limit(mu[x],x,inf) Also: (%i25) mu[x] : 42$ (%i26) limit(mu[inf],x,inf); (%o26) limit(mu[x],x,inf) (%i27) ev(%); (%o27) 42  >Comment By: Dieter Kaiser (crategus) Date: 20100605 22:20 Message: With revision 1.99 of limit.lisp we get (%i1) limit(mu[inf],x,inf); (%o1) mu[inf] Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1969790&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 18:12:01

Bugs item #2960403, was opened at 20100227 14:57 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: spurious floats in asksign Initial Comment: (%i3) integrate(1/(x^2 + x + b)^2,x); Is b0.25 positive or negative?pos; (%o3) (4*atan((2*x+1)/sqrt(4*b1)))/(4*b1)^(3/2)+(2*x+1)/((4*b1)*x^2+(4*b1)*x+4*b^2b) (%i4) build_info(); Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 (%o4)  >Comment By: Robert Dodier (robert_dodier) Date: 20100605 12:12 Message: For my part, I am inclined to revert r1.18 src/db.lisp. I am guessing the changes in that revision are largely nonfunctional. If there are revisions after 1.18, we'll have to reapply them. But db.lisp is so obscure that at this late date, we are better off avoiding any changes to it.  Comment By: Dieter Kaiser (crategus) Date: 20100308 07:32 Message: A further oberservation: The bug is visible when we put in addition a fact into the assume database: (%i2) assume(notequal(4*b1,0)); (%o2) [notequal(b,1/4)] (%i3) asksign(4*b1); Is b0.25 positive or negative? This is done by the integration routine too. This indicates that we have a problem with the assume database alone. As reported the bug is not present in Maxima 5.18. I have located the problem in the following revision: Revision 1.18  (view) (download) (annotate)  [select for diffs] Fri Apr 3 17:27:07 2009 UTC (11 months ago) by are_muc Branch: MAIN Changes since 1.17: +243 208 lines Diff to previous 1.17 If I go back to revision 1.17 of db.lisp the bug vanishes, but it is present with revision 1.18. Unfortunately, the change seems to be very subtle and about 240 lines have changed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100301 14:27 Message: Some observations: (1) The bug has been introduced between Maxima 5.18 and Maxima 5.19. Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(1/(x^2 + x + b)^2,x); Is 4 b  1 positive or negative? Maxima 5.19.2 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(1/(x^2 + x + b)^2,x); Is b  0.25 positive or negative? (2) The bug is not reproducible with asksign alone. We can trace $asksign to see the involved expression: (%i1) :lisp (trace $asksign) ($ASKSIGN) (%i1) integrate(1/(x^2 + x + b)^2,x); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is b  0.25 positive or negative? That is the expression which is passed to $asksign and it works as expected: (%i3) asksign(ratsimp(4*b+1)); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is 4 b  1 positive, negative, or zero? Perhaps we have a global switch or flag which is set by the integration routines and changes the behaviour of $asksign. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 17:01:47

Bugs item #2977217, was opened at 20100326 12:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima can not integrate x*exp(1/2*(xm)^2) Initial Comment: Maxima can not integrate the function x*exp(1/2*(xm)^2) Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(x*exp(1/2*(xm)^2),x); 2 (x  m) /   [ 2 (%o1) I x %e dx ] / The correct solution would be (%i2) diff(exp(1/2*x^2+m*x1/2*m^2)+1/2*m*sqrt(%pi)*sqrt(2)*erf(1/2*sqrt(2)*x1/2*m*sqrt(2)),x); 2 2 x m 2 x m  (  )   + m x   sqrt(2) sqrt(2) 2 2 (%o2) m %e  (m  x) %e  >Comment By: Robert Dodier (robert_dodier) Date: 20100605 11:01 Message: Wow, that's pretty surprising. Maxima can solve integrate(exp((1/2)*(x  m)^2), x) so why not this one?  Comment By: uhlst (uhlst) Date: 20100327 08:45 Message: Thank you for showing this "trick" with changevar. Is there a way that Maxima automatically does the correct substitution without giving it a hint with changevar? If e.g. the "1/2" in the exponent is removed, then Maxima has no problem to do the integration. Does Maxima not try itself some substitutions if integrate is called?  Comment By: Aleksas Domarkas (alex108) Date: 20100326 14:40 Message: (%i1) S:'integrate(x*exp(1/2*(xm)^2),x); (%o1) integrate(x*%e^((xm)^2/2),x) (%i2) changevar(S, y=xm, y, x); (%o2) integrate((y+m)*%e^(y^2/2),y) (%i3) ev(%, nouns); (%o3) (sqrt(%pi)*m*erf(y/sqrt(2)))/sqrt(2)%e^(y^2/2) Solution: (%i4) sol:subst(y=xm,%),rootscontract; (%o4) sqrt(%pi/2)*m*erf((xm)/sqrt(2))%e^((xm)^2/2) Test: (%i5) diff(sol,x)first(S)$ (%i6) expand(%); (%o6) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 16:03:40

Bugs item #2996106, was opened at 20100503 21:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996106&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: at(diff(f(x,y),x,1,y,1),[x=a,y=b]) is wrong Initial Comment: The following is wrong. The equation y=b is substituted into the expression: (%i7) at(diff(f(x,y),x,1,y,1),[x=a,y=b]); (%o7) 'at('diff(f(x,b),x,1,b,1),[x = a,y = b]) The correct result is 'at('diff(f(x,y),x,1,y,1),[x = a,y = b]) The error is present since Maxima 5.20. The problem is in the routine substexceptsecondarg which has been added with revision 1.37 of comm.lisp. A trace of this routine shows the wrong subsitution: (%i7) at(diff(f(x,y),x,1,y,1),[x=a,y=b]); 0: (SUBSTEXCEPTSECONDARG $A $X ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 0: SUBSTEXCEPTSECONDARG returned ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1) 0: (SUBSTEXCEPTSECONDARG $B $Y ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 0: SUBSTEXCEPTSECONDARG returned ((%DERIVATIVE SIMP) (($F SIMP) $X $B) $X 1 $B 1) (%o7) 'at('diff(f(x,b),x,1,b,1),[x = a,y = b]) Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100605 18:03 Message: Fixed in comm.lisp revision 1.52. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996106&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 13:59:06

Bugs item #2013668, was opened at 20080708 19:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&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  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: floor/ceiling(NaN) => finite number Initial Comment: floor(gamma(250.0)) => an integer near 2*10^308 (floatmax). But gamma(250.0) is returning a NaN, so floor should give an error. Of course it shouldn't, but it's better if other code would be NaNproof. GCL's floor function is the culprit (the CL spec seems to be silent on NaN behavior, though you'd think that (floor NaN) should be an error). simpfloor and company should check explicitly for NaNs. This is easier said than done, since in GCL (= (gammalanczos 250.0) (gammalanczos 260.0)) => t, but NaNs are supposed to compare nonequal to themselves.... What's a reliable test for NaN/inf in GCL? Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20100605 15:59 Message: As written in the last posting gamma signals an overflow error for GCL and Lisps too. This has changed with revision 1.22 of csimp2.lisp. The example of this bug report no longer gives a wrong answer. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080922 00:28 Message: gammalanczos no longer returns a float value beyond extreme values (csimp2.lisp, Rev. 1.22). Maxima signals an overflow error. Therefore Maxima no longer calculate a wrong result for floor(gamma(250.0)) too. I think for this special example the bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&group_id=4933 